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

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>

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.

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

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions