text elements not listed elsewhere allow name from subtree #282
Comments
|
Seems that many of these elements should fall under #160 and should have naming prohibited. While understood this doesn't match chrome/firefox/safari, removing the name from subtree step would then mean |
|
We are talking about implementation behavior in regards to use of subtree in accname calculation: if the dominant/interoperable behaviour in implementations diverges from what is defined I suggest it be removed as @asurkov suggests. On @scottaohara's point Anyway having a quick look at the behaviour (test case throws up questions): Why is a span with an and then on Mac The accname exposure differs across browser (resulting in different VO announcements (no name for Labeling of |
many of these elements indeed fall under #160 description, however I'm not sure whether that issue should be fixed at all. If author puts @title on an element having no semantics like HTML:span, then I suppose it's made on purpose - indeed it creates a tooltip on mouseover, so the user can interact with the element. Also it affects (or should affect) on accessible name, since the element may be considered interactive. As an example, Firefox creates an accessible object for such elements, while otherwise it wouldn't, i.e if any HTML element has title attribute on it then Firefox creates an accessible object and expose @title as accessible name. Anyway, #160 is a different issue and can be (should be) handled separately. This issue will align the spec with implementations which is good :) |
me neither, I suppose it's not different from AT perspective if author puts aria-label on these elements.
I bet they aren't. Not sure if HTML-aam spec covers this (if not then it should), but implementations should be aligned.
I don't recall NSAccessibility, but your findings suggest that title and aria-label exposed differently on mac. Not sure, but perhaps it has a reason? cc'ing @cookiecrook |
|
still not sure i agree that See current working definition of A place to start for annotations information (for those who may be unfamiliar) would be ARIA issue 1109. If none of this matters in context of this issue, then I'll be happy to go muddle over other things :) but just figured it was worth pointing out regarding the annotation work / wondering if it'd be at all possible to just indicate these elements are represented by their subtree, and shouldn't be named instead. or is that too out there of an idea to be feasible? |
|
I don't understand the whole discussion, since I assume that Accname is the specification that governs all this. In HTML-AAM, only the results derived from Accname are described in an easily understandable way. That means that the chapter in HTML-AAM cannot be changed without changing Accname, unless both specifications contradict each other. If something is to be changed in Accname, it should be discussed there, right? Apart from that, according to Accname, for all elements that are allowed to have a name, the name is always derived from the subtree (unless there is an aria-label, aria-labelledby, or other higher-level label). Only if there is no label the label can be determined from the title. |
aria-desription like HTML title attribute are indeed represent a concept of accessible description. However, accessible name is a primary characteristic the AT deals with, so an element having no name but having description is less typical/accessible than an element with name but without description. So historically the browsers repaired accessible name if none was provided explicitly (like HTML label or aria-label), and they used HTML title attribute as a last resort (that's why HTML-aam spec lists HTML title attribute in the end for each element).
I'd say it's not typical for HTML:time and all other elements (not listed elsewhere) to have title attribute or aria-label, because as you correctly noticed these elements are represented by their subtrees, but if they do, then I suppose that was author intention and the browsers should attempt to build an accessible name for those. I'd say these elements are like HTML:p elements (grouping/section content elements), and I'd expect them treated similarly. |
correct
not necessary, because accname spec delegates name computation rules from native markup. Previously (iirc) it also allowed to specify which elements support name computation from subtree. However now I see accname regulates that by listing roles that allow name from content, https://www.w3.org/TR/wai-aria/#namefromcontent. Also see accname alg F https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te So actually it makes another reason why elements not listed elsewhere shouldn't support name computation from content: these elements have no mapping to ARIA roles and thus don't support name from content. |
|
Thank you @asurkov ! |
|
In ARIA we have some roles that must not be named: https://w3c.github.io/aria/#namefromprohibited. It would make sense if all equivalent HTML elements were also not allowed to be named (whether with title attribute, content or aria-label/aria-labelledby). The question is, what should screen readers output when unnamed elements get the focus, are displayed in the element overview, or are reached with quick navigation? In all these cases, it would be better to output the content or part of the content instead of not outputting anything at all. This already works in the screen readers, but in my opinion it is not specified |
…name from content Text level elements are not mapped to ARIA roles, but ARIA name computation alg strictly defines roles which allow name from content; also the behavior doens't match implementations
Seems like we should, but also perhaps a different issue. Shall I go and file it? |
Yes |
|
I would again submit that's what #160 should be for. Consider prohibiting naming of elements. Yes. |
It it about JAWS-test comment or this issue or both? |
|
Specifically about JAWS-Test's comment, but both really. Certain elements, including the ones in this thread, really shouldn't be named and should be represented by the contents of their subtree. A bit of clarity there though. The naming prohibited in ARIA 1.2 is not a MUST, as naming such elements/roles is done in the wild now and it was not ARIA's intent to completely remove any naming mechanisms for those elements, but rather to inform authors that the elements shouldn't receive a name due to lack of consistently in it being exposed / desire that these elements really shoudn't be named. My comment was more to the point that we dont' need another issue filed for prohibiting of naming, as 160 already exists. Per our earlier discussion in this thread, it was mentioned that 160 should be treated separately and I agree we should stick to that. |
Ok, good, it makes sense. Let's keep the discussion at #160 issue then? What do we do about this issue and PR #283 in particular? Do we still want to align the spec with implementations before #160 is sorted out? |
…name from content (#283) Text level elements are not mapped to ARIA roles, but ARIA name computation alg strictly defines roles which allow name from content; also the behavior doens't match implementations Co-authored-by: Scott O'Hara <[email protected]>
text elements not listed elsewhere like time, strong, etc allow name from subtree [1], these elements are often not exposed to the accessible tree as individual objects but if they are, they are not interactive and thus shouldn't be treated different from HTML:p (section and grouping content elements). Also the spec doesn't match Chrome/Firefox/Safari implementations.
If no objections, then I suggest to remove 'Otherwise use the text element's subtree.' from 5.17.1.
cc'ing @joanmarie, @aleventhal @cookiecrook @jcsteh
[1] https://w3c.github.io/html-aam/#text-level-elements-not-listed-elsewhere
The text was updated successfully, but these errors were encountered: