Implementation concerns over Orphaned Role requirements in Core-AAM, HTML-AAM… and possibly elsewhere.

[cookiecrook]

Core-AAM Spec prose:

When an element has a role but is not contained in the required context (for example, an orphaned listitem without the required accessible parent of role list), User Agents MUST ignore the role token, and return the computedrole as if the ignored role token had not been included.

<div role="listitem"> <!-- Author error: orphaned listitem. computedrole returns "generic" -->

<div role="list"> <!-- computedrole returns "list" -->
  <div role="listitem"> <!-- computedrole returns "listitem" in the required context. -->

Cite: https://w3c.github.io/core-aam/#roleMappingComputedRole

While working through WPT tests for Interop 2024, we've received some additional implementation concerns about the "orphaned roles" prose. Seems like one or more implementations may be working around this in the test context primarily, which defeats the purpose of testing… I'm opening this new ARIA issue and possibly moving some of these tests to .tentative files.

Some Concerns

• Engines tend to leave some of these orphaned contexts (list items, cells, etc) for the AT to resolve, since the role distinction does not actually matter until such a time as the AT tries to access it. AT can detect whether the structure is valid, and ignore irrelevancies at user-access time. Requiring the engines to manage these author inconsistencies in real-time (even when not being accesses) puts burden on the implementor and it can be passed to the user in the form of a performance hit.
• Instead of penalizing the user with a perf hit, at least one implementor considered "passing" this requirement in the test context only, which defeats the purpose of testing and the AAMs. After discussion, we agreed that is not ideal and should raise the issue instead.
• The ARIA spec acknowledges that most roles should not change, but there are scenarios (like display:contents), where a parent's implicit role may may change due a responsive layout update, causing a cascade of role and style dependencies below. Sometimes a descendant may be disconnected from it's parent context inadvertently, putting additional work on the web engine's accessibility implementation to invalidate the role of an item unexpectedly...
• There are also some edge cases (but real cases) I can think of where reverse lookups are necessary to comply with this requirement: As one example, and orphaned list item that is reference-included into a list via aria-owns from elsewhere in the DOM.
• I anticipate adding more examples to this list…

Since the ~"orphaned roles must be invalidated" rule is a relatively new requirement, and since there have been a few implementation concerns raised, I suggest we move those tests to .tentative and bring them back once concerns are resolved or the issue is otherwise closed.

[cookiecrook]

@nmlapre @jcsteh @twilco @aleventhal @minorninth @benbeaudry @scottaohara

[spectranaut]

Discussed briefly during new issue triage: https://www.w3.org/2024/04/25-aria-minutes.html#t01

[jcsteh]

Aside from the implementation concerns, a user has reported that this does change behaviour for sites in the wild. See this Mastodon thread. Examples include the stories list in Instagram and the navigation bar on the Synchresis Solutions website. Obviously, those sites are violating the spec, but enforcing this in Firefox has changed things unexpectedly for that user, and I'm not sure that's a good thing. I'd argue that backwards compatibility trumps correctness in this case, especially given that there are other concerns here.