Propose CSS selector like *:role('heading') once we have Element.computedRole() in a draft #2
Comments
is |
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. |
@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? |
Reviewed this ticket with APA. Consensus that this may be for AOM @alice |
@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. |
@digilou wrote:
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. |
Also, in case the history is not clear:
That's why I'm proposing this issue be closed. |
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. |
Awaiting comment from Paul Grenier |
@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. |
@AutoSponge wrote:
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. |
This issue was originally raised in the APA tracker as ISSUE-589. Migrating to CSS A11Y.
The text was updated successfully, but these errors were encountered: