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 accessed) puts burden on the implementor. This burden 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 implementing engineer considered "passing" this requirement in the test context only, which defeats the purpose of testing and the AAMs. After discussion, parties agreed the "workaround for testability" is not ideal and should raise this issue instead. (This also raised the question: why the need the RFC req if the AT user interface doesn't need it? Why mandate behavior that doesn't actively benefit the author or end user?)
• 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.
• Update: mentioned below is a real scenario where Firefox's new implementation of this rule exposed an author error, and invalidated a role (tab) that the author had intended and the user had come to expect. Repairing these unintentional authoring errors for the sake of the user should not be explicitly disallowed by the spec.

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.

[jnurthen]

Proposed for deep dive on July 11, 2024 - led by @cookiecrook

[cookiecrook]

FWIW, we are pulling those WPT tests out to tentative with this PR.

• Move orphaned role tests to tentative. web-platform-tests/wpt#46769

Only Gecko has implemented the change so far (and is reconsidering, see above). WebKit does not plan to implement. I haven't heard definitively from @aleventhal, @dtsengchromium, or others at Chromium, but I expect they will not want to implement the change given the other concerns and soon-to-be-removed WPT tests.

[aleventhal]

I believe @tranjocelyn has already implemented this in Chromium.

[tranjocelyn]

Approximately half have been implemented so far in Chromium, specifically the ones in roles-generic, grid-roles, and list-roles.

[aleventhal]

It's possible that not all of these rules are harmful. Should we look at these one by one or just carte blanche axe them all?

[cookiecrook]

@aleventhal wrote:

Should we look at these one by one?

For the sake of tomorrow's Deep Dive discussion, the list of core ARIA roles with "Required Accessibility Parent Roles" is below. There are likely more in HTML-AAM and other AAM specs.

• caption
• cell
• columnheader
• gridcell
• listitem
• menuitem
• menuitemcheckbox
• menuitemradio
• option
• row
• rowgroup
• rowheader
• tab
• treeitem

[cookiecrook]

And related mappings from HTML-AAM to consider in a similar context:

• aside (scoped to the body or main element) versus aside (scoped to a sectioning content element)
• footer (scoped to the body element) versus footer (scoped to the main element, a sectioning content element)
• header (scoped to the body element) versus header (scoped to the main element, or a sectioning content element)
• option (in a list of options or represents a suggestion in a datalist) (Note: HTML-AAM doesn't list the comparable select>option context)
• select (with a multiple attribute or size attribute having value greater than 1) versus select (with NO multiple attribute and NO size attribute having value greater than 1)
• td (ancestor table element has table role) versus td (ancestor table element has grid or treegrid role)
• th (is not a column header, row header, column group header or row group header, and ancestor table element has table role) versus th (is not a column header, row header, column group header or row group header, and ancestor table element has grid or treegrid role) versus th (is a column header or column group header) versus th (is a row header or row group header)

[cookiecrook]

DPUB-ARIA or DPUB-AAM may have some too... as one example:

• doc-example inherits from figure, which can be the accessibility container for caption.

[accdc]

• role=radio ?

[cookiecrook]

All implementors (and other WG members) in the call today concluded to remove the Core-AAM RFC requirement here:

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.

…and replace it with either a note (or perhaps an RFC MAY) explaining that this remains an author error, but the spec is permissive in the way user agents attempt to reconcile this error for the benefit of users. The WPT tests will removed with comments pointing to this new note and related issues.

If and when there is a reason to address one of these instances individually (for example, #2137 or other specific behavior defined in HTML-AAM), we should discuss those individually, rather than broadly disallowing the implementations to repair an author error.

[cookiecrook]

@scottaohara was not able to make the meeting, but expressed some concern about the conclusion afterwards. He and I will meet tomorrow to discuss, and I'll share another update.

[scottaohara]

and just to clarify that - my concerns are specific to HTML element implicit roles. i'm not overly concerned with this decision for explicit author defined ARIA roles.

[scottaohara]

just spoke with @cookiecrook and we confirmed that the agreed upon update to core aam is fine, and that that update doesn't necessarily mean that any current / proposed behavior for HTML elements which have/could have contextual roles need to be altered.

we will do a review/re-review of the contextual roles of HTML regardless. but if anything needs to change there, it'll be a separate effort than the decision that was made about the core aam change.