scottaohara
commented
2 years ago appreciate you outlining all this, as it's giving me something to wrap my head around in a much easier way. Though with that said, in regards to the above i'm unclear what would happen with the following use case i mentioned in the our last WG meeting
<a href=...>
<article>
content goes here
</article>
</a>i see article is mentioned as never traversable, so, would this not still produce a link without an accessible name? if so, maybe there needs to be another designation? Unless "only when focusable" doesn't necessarily refer just to the element, if focusable, but also a parent/ancestor element that would be nameless otherwise?
I realize you said that the lists are not set in stone, but yeh, i'm not sure i understand how some roles like banner or article are in one category, but contentinfo and group are in another.
Thanks again for the work on this Bryan. Regardless of my questions/comments above, i'm sure this'll help move us forward.
accdc
jnurthen
jcsteh
JAWS-test
MelSumner
spectranaut
joanmarie
MarioBatusic
cookiecrook
As we spoke of during the last ARIA meeting, there needs to be a way of defining synchronicity between the ARIA spec and the AccName spec regarding which roles are recursively traversed.
Since the time when this topic was first discussed, reference https://lists.w3.org/Archives/Public/public-aria/2017Jun/0057.html This level of definition was never added to the ARIA spec, even though browsers such as Chrome and others already have logic for this built into their AccName implementations.
As a result of this, it was exceedingly difficult to find a way of adding this to the AccName spec because there was no supported grouping mechanism within the ARIA spec to validate implementation. Unofficially, whether or not a role supported “name from content” was referenced instead for this logic within the ARIA spec within step 2H by referring back to step 2F, but this has led to additional confusion because there are times when roles must be traversed even if they don’t support name from content, and there is no way of definitively saying it should be one way or another given the lack of definition within the ARIA spec. This leads to additional disagreement and makes it impossible to achieve interoperability, which is what the specs strive to achieve.
Since the current grouping mechanism of whether or not a role supports “name from content” is not sufficient for this purpose, a new mechanism needs to be added that can provide this additional level of specificity. This will make it possible to easily add logic to the AccName algorithm to refer back to this grouping mechanism within the ARIA spec to identify which role should or should not be traversed and under which circumstances.
Currently, at the end of each role section in the ARIA spec is a table that defines whether that role supports “name from content”.
I propose to add a new row to that same table that defines whether the role is “Traversable”.
Traversable would support 3 values, “Always”, “Never”, and “When Focusable”.
The word “Traversable” would need to be added to the Terms list within the ARIA spec to specify its purpose. E.G. To specify whether or not the content of a role is traversable within the AccName computation and under which circumstances. (Or whatever…)
These three values (Always, Never, and When Focusable) match the functional criteria that is built into the browsers based on prior agreements when this was discussed in the past.
The meanings of Always and Never are clear in context, though it is important to note that the value When Focusable refers to the circumstance when either the role or one of its ancestor elements is focusable. This definition is not the same as saying that the role is traversable only when the role receives focus. This definition is meant to define that it will be traversable in all cases when the role or one of its ancestor elements is focusable regardless where focus resides.
Officially defining these within the ARIA spec will remove any ambiguity and ensure future interoperability as each spec evolves.
The following role list mostly matches what was originally discussed for this purpose, which includes updates to the ARIA spec and relevant guidance since then. It can be modified as needed to ensure agreement between implementors.
Always Traverse
button, checkbox, heading, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, slider, switch, tab, tooltip, treeitem
Never Traverse
alert, alertdialog, application, article, banner, complementary, dialog, document, feed, figure, form, grid, img, listbox, log, main, marquee, math, menu, menubar, navigation, radiogroup, region, search, searchbox, separator, tablist, tabpanel, textbox, timer, toolbar, tree, treegrid
Traverse Only When Focusable
cell, columnheader, combobox, gridcell, contentinfo, definition, directory, group, list, note, row, rowgroup, rowheader, scrollbar, spinbutton, status, table, term
As noted, the above lists are not set in stone and we can hammer out which ones we can all agree on. (I may have overlooked a role so please suggest where to add if so.)
After this is added to the ARIA spec, it will then be possible to add a relatively simple step to the AccName algorithm to handle cases of whether or not a role is traversable and refer back to whether it is either “Always”, “Never”, or only “When Focusable”.
Feedback is welcome.
All the best, Bryan