w3c
Unexpected accessible name for elements having a tooltip and are named from content containing elements that are not named from content
Consider the following HTML example (copy the data URL in a browser to test):
data:text/html,<a href="https://example.com/" title="Accessible name for my link"><article>This text will be hidden from screenreaders</article></a>
This link is named by the title attribute, which in my opinion is unexpected but seems to be correct according to this spec. The article is not named by content and has no aria-label, so that results in an empty accessible name, causing a fallback to the tooltip (title attribute). This can be fixed by setting a role=none on the article.
I would never write such HTML, but found an example of this while auditing a website for accessibility.
Hi, actually this is expected based on the role of the element within the link. Due to the complexity of the algorithm and the requirement that it be recursive, there is logic to exclude elements that don't support "name from content" when tunnelling into elements as part of the name computation. The reason why the article does not work in this case, is because role=article does not support name from content. If this were changed to be all inclusive, it would break many other types of widget constructs across the web, such as a heading element that includes a select element for example, and many other examples that regularly occur in the wild. There is a current discussion about how we can document this better in the spec, which is presently ongoing, but I agree it should be made clearer that this should be easier to understand.
One other thing that might not be clear is that all elements have implicit roles, even when there is no explicit role attribute. This follows the ARIA-HTML spec where these associations are documented. https://www.w3.org/TR/html-aria/
My apologies if you are already aware of this. :)
@accdc I was aware of this, apologies accepted :)
After testing this in two browsers and seeing similar results I worked through the computation manually and discovered wat is going on, which really was an educational experience. I also see that just making everything being able to be named from content will create a mess. If there is a public discussion about this other then here and in #120, please point me to it, I'd be interested in following that.
@accdc if this is the case then why does DIV not do the same. That maps to generic which has accessible name prohibited.
<a href="https://example.com/" title="Accessible name for my link"><div>This text will NOT be hidden from screenreaders</div></a>
Note - I'm not arguing to change this behaviour as making this example use the title would break the web.
Simply put, because a div acts much like role=presentation and thus does not come into play in the recursion algorithm. The generic role is not called out in the algorithm for special treatment. This is true for all of the elements that are structural and not assigned to implicit roles.
Figure in contrast, specifically maps to role=figure in the accessibility tree, and thus must be subject to the same rules when computed, even if this means following the implicit naming convention for that construct.
This is not a new concept, but the same issue applies for SVG elements where the internal structure dictates the SVG name, so too does fieldset (mapped to role=group) if you include a legend within it, and so on.
I don't understand this comment. Where in the Accname spec is this written down? Div maps to role=generic in the accessibility tree just as much as figure maps to role=figure. Neither of these allow nameFrom: contents so why wouldn't the same rule apply to both? There is something missing here. Chromium has 3 categories of things in its accessible name code. https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/modules/accessibility/ax_object.cc;drc=2f782f3d5fa2e26a84d24f8bede7e3dfaeccf397;l=5155
- // Get their own name from contents, or contribute to ancestors
- examples button, checkbox, heading, link, switch, tab
- // ----- No name from contents -------------------------
// These never have or contribute a name from contents, as they are
// containers for many subobjects. Superset of nameFrom:author ARIA roles.
- examples alert, comment, grid, table, menu
- // ----- Conditional: contribute to ancestor only, unless focusable -------
// Some objects can contribute their contents to ancestor names, but
// only have their own name if they are focusable
- examples canvas, caption, details, footer, generic, list, listitem, paragraph
If one of the user agents has 3 categories (and I believe Firefox does too from memory) and the spec doesn't then IMO we have a problem that needs resolving in the spec.
@bramd, regarding discussion, did you find https://github.com/w3c/accname/discussions/113?
Apologies for taking so long in getting back, was out sick for a while.
"If one of the user agents has 3 categories (and I believe Firefox does too from memory) and the spec doesn't then IMO we have a problem that needs resolving in the spec."
That's basically what I was saying, that we need some better clarification in the spec regarding this.
E.G. If a div that maps to role=generic does not support name from content and thus should not be traversed, how would a link that has a div and text within it get an accessible name? The AccName spec doesn't say that elements with role=generic should not be traversed, or it shouldn't if somebody added this.
Regarding the figure element, take the following example using the MDN example page at: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure
Using the example given, what is the accessible name for this button, and what makes that clear in the AccName spec as it currently stands?
<div role="button" tabindex="0">
<figure>
<img src="/media/cc0-images/elephant-660-480.jpg"
alt="Elephant at sunset">
<figcaption>An elephant at sunset</figcaption>
</figure>
</button>
I just tested this in Chrome Beta, and it actually works as I expect it too, it actually does use the internal text to convey the accessible name.
So, from what I understand from this thread, there should be no accessible name for this button, and that is the correct thing to do in this case?
Please correct me if I am misunderstanding all of your points here. I'm still not feeling well so it may be affecting my understanding a bit.
I believe it was to your last message.
"I don't understand this comment. Where in the Accname spec is this written down? Div maps to role=generic in the accessibility tree just as much as figure maps to role=figure. Neither of these allow nameFrom: contents so why wouldn't the same rule apply to both?"
@accdc
The AccName spec doesn't say that elements with role=generic should not be traversed, or it shouldn't if somebody added this.
It kind of does. 2F says
Otherwise, if the current node's role allows name from content, or if the current node is referenced by aria-labelledby, aria-describedby, or is a native host language text alternative element (e.g. label in HTML), or is a descendant of a native host language text alternative element:
div maps to role=generic - role generic does not allow name from content so according to this its descendents should not be traversed.
This is obviously not correct so we need to fix it. Maybe what we meant to say (which was the same thing at the time) is if the current node's role is NOT only author. This would allow generic etc to still descent into their contents.
@jnurthen can you clarify this bit
Maybe what we meant to say (which was the same thing at the time) is if the current node's role is NOT only author. This would allow generic etc to still descent into their contents.
