Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
michael-n-cooper opened this issue Apr 20, 2017 · 12 comments

Comments

@michael-n-cooper
Copy link
Member

@michael-n-cooper michael-n-cooper commented Apr 20, 2017

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

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Apr 23, 2017

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
Copy link

@cookiecrook cookiecrook commented Apr 24, 2017

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
Copy link

@bkardell bkardell commented Apr 26, 2017

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

@digilou
Copy link
Contributor

@digilou digilou commented Jul 29, 2020

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

@cookiecrook
Copy link

@cookiecrook cookiecrook commented Aug 24, 2020

@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>
  1. 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
Copy link

@cookiecrook cookiecrook commented Aug 24, 2020

@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
Copy link

@cookiecrook cookiecrook commented Aug 24, 2020

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
Copy link
Contributor

@digilou digilou commented Aug 25, 2020

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 digilou closed this Aug 26, 2020
@digilou digilou reopened this Aug 26, 2020
@digilou
Copy link
Contributor

@digilou digilou commented Aug 26, 2020

Awaiting comment from Paul Grenier

@AutoSponge
Copy link

@AutoSponge AutoSponge commented Aug 26, 2020

@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
Copy link

@cookiecrook cookiecrook commented Aug 26, 2020

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

@digilou digilou closed this Sep 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants