Open cookiecrook opened 4 months ago
Just an implementer note: I wrote a patch for Gecko that implements orphaned child role fallback in the absence of the relevant parent.
Main takeaway: this introduces a fair bit of tree walking. Every time the UA sees a potential orphan, it has to walk up the tree a bit, chasing pointers. I wouldn't expect a massive performance impact, but it is non-trivial processing in a very commonly-used function.
Seems like the relevant reqs may be covered sufficiently in the Core-AAM spec. https://github.com/web-platform-tests/wpt/pull/45032#pullrequestreview-1940519479
If so, we may be able to close this one.
@twilco brought up a related case where the list markup is invalid, but one or more engines still render the bullet, and therefore may need an exception in the mapping spec, if the implementations agree.
<ul>
<div>
<li>one</li>
</div>
<li>two</li>
<li>three</li>
</ul>
And I'm still looking for an RFC-2119 statement that covers the native containment case without an explicitly-defined role attr.
Seems like the relevant reqs may be covered sufficiently in the Core-AAM spec. web-platform-tests/wpt#45032 (review)
The fact that we wrote that so recently, but it was hard to find because you expected to see this kind of normative statement in ARIA, makes me wonder if it belongs in the ARIA spec itsself, in the Required Accessibility Parent Section. Which, btw, allows for the case with the div in the list above, at least in terms of what is a valid "accessibility parent" (intervening generics are ignored when calculating accessibility parent).
Discussed in the ARIA working group today: https://www.w3.org/2024/03/21-aria-minutes.html#t08
@twilco brought up a related case where the list markup is invalid, but one or more engines still render the bullet, and therefore may need an exception in the mapping spec, if the implementations agree.
<ul>
<div>
<li>one</li>
</div>
<li>two</li>
<li>three</li>
</ul>
@scottaohara graciously refiled that one:
Conclusion has been that the UA stylesheet (as defined in HTML) is sufficiently specified behavior to render the bullet. Therefore, HTML-AAM should be updated to expose <li>
as a list item when the bullet is rendered, regardless of whether it's in the context of an <ol>
or <ul>
.
Perhaps this is a good time to remind the group that WebKit uses list bullet render style as one of a number of heuristic ways to determine whether a list is a layout list or semantic list, similar to the table heuristics in all engines.
Note: Unfortunately you need to be logged in to Twitter to see the full thread linked above.
Updated implementer note: I've spent some more time refining and testing the Gecko patch that walks ancestors looking for required parent roles. After some profiling, I found minimal performance impact, especially since UAs can generally stop traversing at the first non-generic ancestor. It's slightly more complicated for roles that allow intervening groups, but still not bad. Firefox page load time for a table with 10,000 rows was virtually unchanged.
I think it's still possible that pathological cases (e.g., a bunch of gridcells with a million generic ancestors before a row ancestor) would present issues, but I'm not too worried about that.
ARIA spec verbiage could be something like:
~ In scenarios where multiple implementations render semantic styles (such as a bullet on an invalid list item) or consistently remove semantic styles, Accessibility API Mapping specifications MAY make exceptions to the required accessibility parent or child mappings.
then HTML-AAM for example could add an exception like:
"
li
when a list marker is rendered" maps tolistitem
, even if the parent context is invalid
This still needs a lot of word-smithing, but that's the gist I have in mind. @scottaohara?
I'm going to remove agenda, but put the agenda tag back on when you want this discussed with the group again!
@scottaohara and I discussed this today.
Consensus specifically on the listitem issue was that HTML-AAM would change verbiage to something like "li where the accessibility parent is a list" (e.g. ignoring generic in-betweener divs as in @twilco's example above) but truly orphaned list items (outside a list entirely) would still be exposed as generic... Rendered list markers like bullets can/should still be conveyed to AT... Effectively this documents the same end-user behavior today in most AT scenarios, but would result in some test-driven changes like computedrole return values. A few examples:
We did not discuss in detail how this pattern would be applied to contexts beyond list, but I assume @scottaohara plans to do the same for other descendant roles related to their ancestor context... Ignoring generics, and making rules tied to accessibility parent as defined in ARIA. I think this should be reasonably performant in engines because the engine just needs to walk up the ancestor chain to the first non-generic.
We did not discuss invalidating containers due to missing "required" descendants... Such as a <ul>
with no <li>
descendants. I am less concerned if those keep their role defaults.
More on the "required context" topic here:
More recent, overlapping discussion:
In the following Interop Accessibility issue:
@nmlapre rightly calls out that several WPT accessibility "orphan" tests aren't specified in ARIA.
In fact, the error handling portion of the ARIA spec states:
So I plan to move all the orphaned role tests into new WPT files which include
.tentative.
in the file name. This will allow us to get these disputed/invalid tests out of the Accessibility Focus Area, while the ARIA WG decides whether to address this issue in a spec change.As of now, it's an undefined implementation detail so engines could return a different role (though presumably
gridcell
orbutton
) for the above tests. Potential webcompat issues may remain in these cases of author error.