Update image-button-non-empty-accessible-name-59796f.md #1865
Conversation
Added: * failed example 3 * updated "Accessibility Support" section
|
|
carlosapaduarte
added
Rule Update
| @@ -56,6 +56,8 @@ Each target element has an [accessible name][] that is neither empty (`""`), nor | |||
|
|
|||
| There is a known combination of a popular browser and assistive technology that does not by default support `title` as an [accessible name][]. | |||
|
|
|||
| The image button with non-empty `title` attribute but empty `alt` attribute results in a button with empty accessible name on many browsers. On Firefox, instead, the `title` attribute is used as fallback, resulting in a button with `title` attribute value as accessible name. | |||
There was a problem hiding this comment.
I think we should try to write this without naming any specific browsers (like we do in the previous sentence).
There was a problem hiding this comment.
Thanks Carlos,
updated using a generic known popular browser as above.
Co-authored-by: Carlos Duarte <[email protected]>
My mistake; the resulting accessible name of Failed example 3 is empty (except for Firefox), not default "submit query".
Co-authored-by: Jean-Yves Moyen <[email protected]>
Co-authored-by: Jean-Yves Moyen <[email protected]>
| @@ -56,6 +56,8 @@ Each target element has an [accessible name][] that is neither empty (`""`), nor | |||
|
|
|||
| There is a known combination of a popular browser and assistive technology that does not by default support `title` as an [accessible name][]. | |||
|
|
|||
| An image button with non-empty `title` attribute but empty `alt` attribute results in a button with an empty accessible name on many browsers. There is a known popular browser that uses the `title` attribute as fallback even with empty `alt`, resulting in a button with `title` attribute value as accessible name. | |||
There was a problem hiding this comment.
an image and an image button are different things. they have two different naming algorithms for a reason. why are they being merged into one test?
There was a problem hiding this comment.
I agree with you; we were almost talking about the need of a clearer definition for "usable text string" in accessible name computation rules.
That said, this rule is specific for image button elements (we didn't merge image and image button elements int one single test).
As per Inapplicable Example 4
The img element is not a user interface component, and so is not tested for Success Criterion 4.1.2 Name, Role, Value.
that confirms that images are not part of this rule.
There was a problem hiding this comment.
In light of @scottaohara clarification at w3c/html-aam#414 (comment), I think we can rephrase this in the line of
The naming algorithm (+link to relevant HTML AAM part) uses the first non-empty name, but some AU/AT stop at the first existing one, even if empty.
This would make it clear that it is not just some browsers quirks deciding what to do, but an actual bug in some implementation (and would explain why our examples are built following specs and may behave differently on some browsers).
Maybe we can also add a background note in the line of:
Contrarily to images, empty
altdoes not make image button decorative. Image buttons are button and therefore exposed as interactive elements.
which is one on these things that is obvious once stated but maybe not so obvious before seeing it once…
| This image button has a non-empty `title` attribute, but an empty `alt` attribute. This gives the button an empty [accessible name][]. | ||
|
|
||
| ```html | ||
| <input type="image" src="/test-assets/shared/search-icon.svg" title="Search" alt="" /> |
There was a problem hiding this comment.
firefox says search button
chrome has no name (bug)
safari says submit button
firefox is correct here
chrome is wrong by providing no name
safari skips title but at least provides the fallback text.
There was a problem hiding this comment.
In my opinion this might be subjective (and that's probably also why browsers render this example in different ways).
From 4.3.1 input type="image" Accessible Name Computation
4.3.1 input type="image" Accessible Name Computation
1. If the control has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings.
2. Otherwise use alt attribute.
3. Otherwise use title attribute.
4. Otherwise if the previous steps do not yield a usable text string, the accessible name is a localized string of the word "Submit Query".
If none of the above yield a usable text string there is no accessible name.
In our example the alt attribute has been clearly defined as empty (alt=""). Depending on interpretations, we might stop at point 2, considering the alt="" as a choice to make the image decorative, or we can move forward reviewing the title.
Even more important is that for images, the HTML Accessibility API Mapping contemplate (rightly) the specific scenario (4.10 img Element)
4.10.1 img Element Accessible Name Computation
1. If the img element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings.
2. Otherwise use alt attribute, even if its value is the empty string.
NOTE
An img with an alt attribute whose value is the empty string is mapped to the presentation role. It has no accessible name.
3. Otherwise, if there is no alt attribute use the title attribute.
4. Otherwise there is no accessible name.
Combining these two items, might result unclear which are expectations.
Interesting also the example provided by @Jym77 when images are not loaded.
There was a problem hiding this comment.
In addition, if these are the expectations, it is necessary that all browsers move in this direction; right now, this example might be an important barrier for some user depending on the technology the user is using.
There was a problem hiding this comment.
In the light of the recent clarifications, this should be a Passed Example indeed (since the empty alt does not provide a "usable string").
Description can say that the image button has name "Search", but some UA/AT (incorrectly) either use the empty alt or the fallback "Submit query".
| @@ -56,6 +56,8 @@ Each target element has an [accessible name][] that is neither empty (`""`), nor | |||
|
|
|||
| There is a known combination of a popular browser and assistive technology that does not by default support `title` as an [accessible name][]. | |||
|
|
|||
| An image button with non-empty `title` attribute but empty `alt` attribute results in a button with an empty accessible name on many browsers. There is a known popular browser that uses the `title` attribute as fallback even with empty `alt`, resulting in a button with `title` attribute value as accessible name. | |||
There was a problem hiding this comment.
In light of @scottaohara clarification at w3c/html-aam#414 (comment), I think we can rephrase this in the line of
The naming algorithm (+link to relevant HTML AAM part) uses the first non-empty name, but some AU/AT stop at the first existing one, even if empty.
This would make it clear that it is not just some browsers quirks deciding what to do, but an actual bug in some implementation (and would explain why our examples are built following specs and may behave differently on some browsers).
Maybe we can also add a background note in the line of:
Contrarily to images, empty
altdoes not make image button decorative. Image buttons are button and therefore exposed as interactive elements.
which is one on these things that is obvious once stated but maybe not so obvious before seeing it once…
| This image button has a non-empty `title` attribute, but an empty `alt` attribute. This gives the button an empty [accessible name][]. | ||
|
|
||
| ```html | ||
| <input type="image" src="/test-assets/shared/search-icon.svg" title="Search" alt="" /> |
There was a problem hiding this comment.
In the light of the recent clarifications, this should be a Passed Example indeed (since the empty alt does not provide a "usable string").
Description can say that the image button has name "Search", but some UA/AT (incorrectly) either use the empty alt or the fallback "Submit query".
Co-authored-by: Jean-Yves Moyen <[email protected]>
Co-authored-by: Jean-Yves Moyen <[email protected]>
| ## Background | ||
|
|
||
| Contrarily to images, an empty `alt` attribute does not make image button decorative; image buttons have a button role and are therefore exposed as interactive elements. Consequently, an empty `alt` attribute does not provide a "usable string" for image buttons and the computation defaults to other means of providing a name. |
There was a problem hiding this comment.
- I don't think you should use
Contrarily to images, you're talking specifically about theimgelement. There are different types of images in HTML. - I'm not sure what that second sentence means. Can you make it clearer?
There was a problem hiding this comment.
- I agree with the 1st item. I'll update "images" with
imgelements.
- About the second sentence
Consequently, an empty
altattribute does not provide a "usable string" for image buttons and the computation defaults to other means of providing a name.
it refers to the previous adjacent Accessibility support paragraph
The input type="image" Accessible Name Computation algorithm uses the first non-empty name, but some user agents and assistive technologies combinations stop at the first existing one, even if empty.
Per input type="image" Accessible Name Computation algorithm, if the alt attribute value consists in a non-usable string the title attribute should be considered, and again, if the title attribute value consists in a non-usable string, the accessible name is a localized string of the word "Submit Query".
For the sake of clarity I'll update
Consequently, an empty
altattribute does not provide a "usable string" for image buttons and the computation defaults to other means of providing a name.
in
Consequently, an empty
altattribute does not provide a "usable string" for image buttons and the computation defaults to other means of providing a name, as defined in input type="image" Accessible Name Computation algorithm.
Does it make sense?
Co-authored-by: Wilco Fiers <[email protected]>
|
As per our conversation, I've removed Passed example 5 and I've opened an issue about how to handle those cases: #1954 |
Added:
Closes issue: #1861
Need for Call for Review:
This will require a 1 week Call for Review
Note: Sorry if I made mistakes while creating the pull request, this is my first pull request and first time I contribute to a GitHub project.
Pull Request Etiquette
When creating PR:
developbranch (left side).After creating PR:
Rule,DefinitionorChore.When merging a PR:
How to Review And Approve