-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify whether author errors in "required accessibility parent/child" (formerly "required context") should be handled by UA #2137
Comments
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. web-platform-tests/wpt#45032 (review) |
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. |
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 |
<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 |
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:
then HTML-AAM for example could add an exception like:
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 |
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.The text was updated successfully, but these errors were encountered: