Propose CSS selector like *:role('heading') once we have Element.computedRole() in a draft #2
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 I guess I never saw this question. Apologies for the tardy reply.
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.
<button role="switch checkbox">which is it? depends.</button>
<button role="checkbox expandorole">valid checkbox, but with optional expando token</button>
<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
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.
Also, in case the history is not clear:
That's why I'm proposing this issue be closed.
@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.
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.
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.