w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
632 stars 120 forks source link

Clarify whether author errors in "required accessibility parent/child" (formerly "required context") should be handled by UA #2137

Open cookiecrook opened 4 months ago

cookiecrook commented 4 months ago

In the following Interop Accessibility issue:

@nmlapre rightly calls out that several WPT accessibility "orphan" tests aren't specified in ARIA.

<button role="gridcell" data-expectedrole="button">x</button>

In fact, the error handling portion of the ARIA spec states:

Excerpt: "…User agents are not responsible for logical validation, such as the following: […] Elements that do not correctly observe required child / parent role relationships or that appear elsewhere than in their required parent…"

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 or button) for the above tests. Potential webcompat issues may remain in these cases of author error.

nmlapre commented 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.

cookiecrook commented 4 months ago

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

cookiecrook commented 4 months ago

If so, we may be able to close this one.

cookiecrook commented 3 months ago

@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.

spectranaut commented 3 months ago

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).

spectranaut commented 3 months ago

Discussed in the ARIA working group today: https://www.w3.org/2024/03/21-aria-minutes.html#t08

cookiecrook commented 3 months ago

@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:

cookiecrook commented 3 months ago

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>.

cookiecrook commented 3 months ago

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.

nmlapre commented 3 months ago

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.

cookiecrook commented 3 months ago

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 to listitem, 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?

spectranaut commented 3 months ago

I'm going to remove agenda, but put the agenda tag back on when you want this discussed with the group again!

cookiecrook commented 3 months ago

@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:

cookiecrook commented 3 months ago

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.

cookiecrook commented 2 months ago

More on the "required context" topic here:

cookiecrook commented 3 days ago

More recent, overlapping discussion: