Brainstorming space for specifying the accessibility tree

[alice]

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:

• what resources authors currently have for understanding the accessibility tree
• terminology for things like roles not defined in ARIA
• places where accessibility tree behaviour is currently surprising as implemented in browsers

to feed into later work on a more fleshed-out document.

[jakearchibald]

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 display: none impacted screen readers, but I made peace with it.

But now it seems like opacity: 0 also hides from screen readers. And display: block will undo the content semantics of a table.

I'm now unsure how far this goes. When I use display: grid, I'm usually expressing a visual style, and wouldn't expect it to be expressed as a grid to a screen reader. If I wanted a semantic grid, I'd have used a table.

It'd be interesting to see an exhaustive list of where css impacts the a11y tree.

[alice]

@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 display: none or opacity: 0, we have no way to know for sure that they actually consider that content semantically relevant - they chose not to expose it to users of the default UI for a reason, and we assume that reason holds true for AT users as well.

The case of styled <table>s is a little different. In that case, we do have a clearer signal as to the author's intent - why would they bother using a <table> if what they wanted was a bunch of <span>s? This seems to me more like a case where the DOM structure could take precedence.

Using display: grid, on the other hand, doesn't necessarily create any kind of table-like layout, so it seems pretty safe to assume the author didn't intend to create a table or grid UI unless they tell us that directly.

[jakearchibald]

we don't want to force AT users to have a worse experience in those cases just to make authors' lives simpler

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.

If an author uses display: none or opacity: 0, we have no way to know for sure that they actually consider that content semantically relevant - they chose not to expose it to users of the default UI for a reason, and we assume that reason holds true for AT users as well.

The case for display: none is much stronger than opacity: 0. display: none and visibility: hidden prevent interactivity. pointer-events: none prevents non-keyboard interactivity. But with opacity: 0 the element remains fully interactive.

We're using an overlaid opacity: 0 element to provide interactivity and accessibility to a canvas.

Using display: grid, on the other hand, doesn't necessarily create any kind of table-like layout

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.

[jakearchibald]

It seems like we do read opacity: 0 content. https://static-misc.glitch.me/screen-reader-label/. So… panic over. Or are we planning to change behaviour there?

[cookiecrook]

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.

• if engines were tuned to remove the render object for opacity:0, the AX tree could change unexpectedly, but I don’t believe this is not a common enough technique to justify a performance tweak.
• when we get around to standardizing an AX tree, this could change as a purposeful decision, but I don’t see a lot of reason to do so.

[jakearchibald]

users expect screen readers to read what’s on screen

I don't think that's such a simple rule. Is opacity: 0 on screen? Is something absolutely positioned -500,-500 on screen? White text on a white background? Etc etc.

But I'm glad we're keeping opacity: 0 items in the AX tree, and also glad that how CSS modifies the AX tree is going to be documented somewhere.

[cookiecrook]

users expect screen readers to read what’s on screen

I don't think that's such a simple rule.

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.

[alice]

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.

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 <table> semantics, in a way that is not entirely predictable to developers.

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.

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.

This is slightly less true on Chrome now, with the changes we made to support display: contents, which causes elements not to have a box (render object/layout object). We now preferentially walk the flattened DOM tree; however, a Node not having a LayoutObject will still cause it to be ignored in the accessibility tree unless certain other conditions are true (such as having display: contents).