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

[cookiecrook]

In the following Interop Accessibility issue:

• Remove orphaned children accessible tests, or clarify ARIA spec web-platform-tests/interop-accessibility#109

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

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]

Seems like the relevant reqs may be covered sufficiently in the Core-AAM spec. web-platform-tests/wpt#45032 (review)

[cookiecrook]

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

[cookiecrook]

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

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]

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

[cookiecrook]

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

• Should the UA stylesheet render li elements with markers if the li is not within a list? whatwg/html#10222

[cookiecrook]

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]

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]

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]

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]

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

[cookiecrook]

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

• Gecko already implemented these role changes for Interop, so end-user SR support is the same on Windows and Mac. (User hears "bullet" then list item text, with no extra role description or list summary)
• WebKit has not yet shipped the change, but VO default verbosity doesn't speak "list item" role description, sinc the user already hears the list summary and bullet... computedrole would change for WPT, but user experience remains unchanged.
• Chrome has not yet shipped the change, and has the same behavior on Mac due to VO's default verbosity, but does speak the longer role description "list item" on these orphaned list items... computedrole would change for WPT, but there would be a minor user experience change for orphaned list items, the "bullet" would remain, but user would no longer hear the extra role description.

[cookiecrook]

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]

More on the "required context" topic here:

• Implementation concerns over Orphaned Role requirements in Core-AAM, HTML-AAM… and possibly elsewhere. #2166
• Revisit moving the "orphaned role" tests to .tentative while ARIA issue discussed web-platform-tests/interop-accessibility#120