-
Notifications
You must be signed in to change notification settings - Fork 59
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
Brainstorming space for specifying the accessibility tree #143
Comments
Generally I'm surprised at how styling impacts accessibility. My original way-back-when understanding was that HTML was for content, and styles were for giving that content visual style. I was originally surprised when I discovered But now it seems like I'm now unsure how far this goes. When I use It'd be interesting to see an exhaustive list of where css impacts the a11y tree. |
@jakearchibald Thanks for the comment! I think this could do with some clarification in the eventual doc/spec. This discussion about the semantics of the DOM vs styling seems to be bubbling up in a few places lately, and I outlined my general thoughts here: w3c/csswg-drafts#3778 (comment) In general, I think we try to find heuristics such that the accessibility tree reflects the semantics of the default UI, rather than the DOM specifically, which makes explaining how the tree gets built tricky. In practice, CSS is absolutely used to create semantics for users of the default UI, and we don't want to force AT users to have a worse experience in those cases just to make authors' lives simpler. If an author uses The case of styled Using |
Absolutely. But usually it goes the other way around. If figuring things out becomes hard, it'll be done correctly less frequently, and the result will be an unintended experience.
The case for We're using an overlaid
It creates a layout where items are laid out in rows and columns. But I agree that it shouldn't expose those columns and rows semantically. |
It seems like we do read |
The current behavior is an implementation detail that aligns with expectations: users expect screen readers to read what’s on screen, not unrendered things in the DOM hidden with display:none. Both display:none and visibility:hidden result in the removal of the render object in WebKit and Blink. Since the AX tree is based on the render tree, these are not in the AX tree by default. Semi-opaque elements (even opacity:0) do get a render block, so they remain accessible. I expect this is unlikely to change unless there is a performance or standards based reason to do so.
|
I don't think that's such a simple rule. Is But I'm glad we're keeping |
I’m not saying that’s a simple rule. I mentioned that here because, this was the logic that led to the decision that the WebKit AX tree (including Blink’s before it forked) should be based off the render tree, rather than off the DOM tree. |
Yeah, it's a tricky line to walk, as you saw with the whole layout table heuristics thing - while handling layout tables certainly made a better experience for users in general while the use of layout tables was prevalent, it also created a situation where we now don't always respect So, while of course I have a lot of sympathy for the argument that making things straightforward will help developers who are trying to create a better experience for users, I think it would be incorrect to ever assume that DOM semantics should be a 1:1 match with accessibility tree semantics - that is not how semantics work. We care about the in practice semantics more.
This is slightly less true on Chrome now, with the changes we made to support |
We began sketching out https://github.com/WICG/aom/blob/gh-pages/accessibility-tree.md, but I thought we might want to capture some thoughts on:
to feed into later work on a more fleshed-out document.
The text was updated successfully, but these errors were encountered: