Propose CSS selector like *:role('heading') once we have Element.computedRole() in a draft

[michael-n-cooper]

This issue was originally raised in the APA tracker as ISSUE-589. Migrating to CSS A11Y.

[patrickhlauke]

is Element.computedRole() implemented in the wild anywhere/still actively being considered by browsers? and/or what is its relationship to phase 4 of the Accessibility Object Model https://github.com/WICG/aom /cc @cookiecrook

[cookiecrook]

This tracker can probably be closed for the time being since computedRole is more likely to be implemented in either a WebDriver interface or AOM. The role selector ended up being much more challenging (because it causes a style recalc) than originally anticipated. IOW, we could implement a simple "default role for tag" or "first recognized role attr token" selector, but to get the real thing, you'd need to spin up too much backing code in the rendering engines, which could dramatically slow page rendering. There may be a way to address this in the future, but there is no need to keep this open in the meantime.

[bkardell]

@cookiecrook is this effectively just bad pre-existing code paths implied by how it's plugging in currently that it is hard to avoid or is there a legit reason that getting the computed role would need something WRT the rendering engine?

[ZoeBijl]

Related posts:

• Reflecting on Roles by Brian
• Cascading Semantic Stylehooks by Michiel

[digilou]

Reviewed this ticket with APA. Consensus that this may be for AOM @alice

[cookiecrook]

@bkardell I guess I never saw this question. Apologies for the tardy reply.

is [the difficulty with :role() selector] effectively just bad pre-existing code paths implied by how it's plugging in currently that it is hard to avoid or is there a legit reason that getting the computed role would need something WRT the rendering engine?

If we were just to match something like an attribute value, it would be easy and account for the 95% case, but that wouldn't be sufficient for a few reasons.

1. Using the selector to display differently based on whether a role was implemented. In the following example, both are valid (checkbox in ARIA 1.0 and switch in ARIA 1.1), so the computed role depends both which version of ARIA the engine is compliant with, and possibly whether the platform supports that role. (Switches are not as common on desktop; tree grids are not as common on mobile, etc.) FWIW, the below examples would also not match the exact [attr=value] selector.

<button role="switch checkbox">which is it? depends.</button>
<button role="checkbox expandorole">valid checkbox, but with optional expando token</button>

2. A DOM based or inferred role selector would also not take into account the heuristic logic used to rule out invalid role usage. For example, an orphaned cell (outside a valid table row) should never be exposed to the accessibility trees... So this malformed table would not be exposed as a cell, despite the explicit role value.

<main><div role="gridcell">role soup</div></main>

So IMO we're left with: There should only be a role selector if we can really make it match the true computed role.

Right now, the implementation for that is more difficult than anyone has agreed to take on. Not impossible, but likely to be prohibitively difficult for some time.

In WebKit (I think this also still applies to Blink), the accessibility tree is based on the render tree, not the DOM tree. Therefore, accessibility has a dependency on the renderer, and the renderer obviously has a dependency on the style parser. Selectors block rendering, so adding a blocking dependency on accessibility would result in a circular reference.

It's possible that could be resolved but it would require such a major re-write in the engines that the :role() selector proposal benefit doesn't justify the implementation cost or the likely fallout risks to stability and performance.

The path proposed now is to add computed role and label only to testing contexts like WebDriver and WPT, where performance and other risk areas can be accounted for and/or mitigated. If this usage becomes popular enough, we can later revisit implementing computed role so that it's available in other contexts. Including perhaps, as a selector.

[cookiecrook]

@digilou wrote:

Consensus that this may be for AOM

Even if we get to AOM Goal 4 (standardized accessibility tree), the the same problems apply. Those would need to be resolved before this could be used more broadly than limited contexts like testing.

[cookiecrook]

Also, in case the history is not clear:

• I filed this issue in the in original ARIA tracker in 2013 as Issue-589. Michael migrated it here.
• I took the proposal to the CSSWG (before the css-a11y group existed IIRC)
• The selector was discussed (cannot recall if rubber-stamped for incubation or formally approved) and we attempted to start implementation.
• The problems listed above arose during the implementation attempt.
• We reported our findings to the CSSWG and the :role() selector was abandoned.

That's why I'm proposing this issue be closed.

[digilou]

Thank you @cookiecrook for chiming in! I'm going to share this at the APA meeting on Wednesday. I'm pretty new here, so any history recalled is helpful to me.

[digilou]

Awaiting comment from Paul Grenier

[AutoSponge]

@cookiecrook In my experience with testing contexts (like the aforementioned WebDriver), the platform is normalized and known prior to runtime. Test authors can assume validity of certain selectors. For runtime decisions, libraries like the ubiquitous jquery offer normalization of edge cases. I'd rather see a role selector with platform variation than no selector. The community, platforms, or individual authors may choose to overcome those differences at runtime while testing contexts get full support.

[cookiecrook]

@AutoSponge wrote:

In my experience with testing contexts (like the aforementioned WebDriver), the platform is normalized and known prior to runtime. Test authors can assume validity of certain selectors.

That's true when the context is limited to testing web applications.

I'm also referring to testing web rendering engines against each other, for example, in the context of WPT, or even WPT utilizing WebDriver. Test authors can assume nothing, because the engines are changing constantly, and regressions occur.

For runtime decisions, libraries like the ubiquitous jquery offer normalization of edge cases. I'd rather see a role selector with platform variation than no selector. The community, platforms, or individual authors may choose to overcome those differences at runtime while testing contexts get full support.

Introducing a web standard API "with platform variation" seems like a non-starter. Doing so would introduce permanent interoperability problems—we already have enough interop issues between browsers. So I don't see the benefit to that, and even if it were specified, I'm confident that multiple vendors would file formal objections.