[css-contain-2] Clarify whether content-visibility: auto subtree elements are visible in accessibility

[vmpstr]

The contain spec level 2 says that content-visibility: hidden elements should be omitted from the accessibility tree.

However, it doesn't say whether content-visibility: auto elements should be included or omitted. It only says that the timing of determining whether to include or omit the element should not differ greatly from non-accessibility path.

We believe that the content-visibility: auto elements should be visible in the accessibility. There is a caveat: in order to keep timing the same not process style, we would assume that the off-screen unrendered elements are visible even if they have something like visibility: hidden, until they are brought into view and style is updated.

/cc @alice @chrishtr

[alice]

It would be worth hearing from AT users and other experts on this.

My sense is that the actual user impact of exposing visibility: hidden and display: none elements (including <script> and <style> elements) inside content-visibility: auto areas to AT will be minimal.

Firstly, I'm imagining it will typically be used on blocks which contain only content - scripts and styles would not tend to be in content which should be rendered on-demand.

Secondly, even if they are in that content, they aren't going to be exposed to users of AT while they're not in or near the visible viewport, because AT doesn't typically provide a way to explore off-screen content in depth, since a majority of users of AT can access the visible content in some way.

The only scenario I can immediately think of where it might be an issue for users is AT find-in-page, which could find content inside of offscreen <script> or <style> elements, cause them to be scrolled into view, and thus cause their styles to be resolved and those elements to be hidden.

I think, given the unlikelihood of this actually happening frequently, it's a reasonable trade-off against the other options we could think of, namely:

• resolve style for all content-visibility: auto elements if AT APIs are being accessed, or
• the current implementation, which effectively doesn't expose content-visibility: auto elements (including headings and landmarks) to AT (since they are exposed as "hidden", analogous to how aria-hidden regions are exposed).

I guess a final option might be to only expose nodes matching a safelist of computed roles, but that sounds like a bit of a can of worms potentially.

@cookiecrook any thoughts? Anyone else to tag in?

[jakearchibald]

Firstly, I'm imagining it will typically be used on blocks which contain only content - scripts and styles would not tend to be in content which should be rendered on-demand.

https://www.theguardian.com/uk has a number of non-empty script & style elements in elements that may benefit from content-visibility: auto.

Secondly, even if they are in that content, they aren't going to be exposed to users of AT while they're not in or near the visible viewport, because AT doesn't typically provide a way to explore off-screen content in depth, since a majority of users of AT can access the visible content in some way.

I hadn't appreciated this. This makes me worry less 😄

The only scenario I can immediately think of where it might be an issue for users is AT find-in-page

I guess we can't detect when this happens? Otherwise, we could deopt at this point, as we do with regular browser find-in-page.

I can imagine similar cases where an AT user looks at the heading structure of the page, but some headings are inside custom 'tab content' of a non-selected tab. This would cause the heading to become hidden when the browser tries to scroll to the heading.

I guess this wouldn't be an issue if the tab UI used the hidden or aria-hidden attribute to hide non-selected tabs. But it might be an issue if the site relies on display: none to hide content from both visual and AT users.

[joelanman]

AT doesn’t typically provide a way to explore off-screen content in depth

isn't the Rotor in Voiceover an example of this?

https://support.apple.com/en-gb/HT204783

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-2] Clarify whether content-visibility: auto subtree elements are visible in accessibility.

The full IRC log of that discussion

<dael> Topic: [css-contain-2] Clarify whether content-visibility: auto subtree elements are visible in accessibility
<dael> github: https://github.com//issues/5857
<dael> vmpstr: We have content-visbility:hidden as not visible in a11y. The auto value does nto explicitly state if it should/should not be exposed. Some dev concerns that chromium does not expose. Would like to clarify in spec that content-visbility: auto elements should be exposed to a11y
<fantasai> seems fine to me, given auto seems to be mainly about delaying rendering of elements until they're on-screen and not about actually hiding the content
<dael> vmpstr: They would be essentially visibile in a11y. Offscreen elements in subtree of content-visbility:auto are visibile in a11y.
<dael> Rossen_: Which is the case with visbility, but not display:none
<dael> Rossen_: Sounds reasonable. Any other opinions?
<dael> florian: I think it's different than visbility:hidden. Not all elements in subtree are accessible. In this case they would all be
<dael> chrishtr: Yes, would make all visbilie even if display:none ancestor
<dael> vmpstr: aria label would be respected so can hide
<dael> fantasai: Seems weird
<dael> Rossen_: Bigger issue. If could to disable hammer of display:none which does nothing, if we distablize that promise different convo
<dael> florian: WE don't want to ignore display:none, but we're ignoring styles and display:none is a style
<dael> fantasai: But if treating as shown you have to look at styles
<dael> vmpstr: Expose nodes to a11y. Any action taken to explore, once the elements come on screen they're rendered. In that case if something is display:none it would disappear from a11y
<dael> Rossen_: Which is the problem. From a11y PoV what you have in youre a11y tree and available to user will be different than what is visible in the view
<fantasai> +1 to Rossen
<dael> Rossen_: Let's say you have a quiz and quiz has answers inside display:none the right answers will be available to those with access to a11y tree
<dael> Rossen_: Breaking display:none for a11y or css is bad
<dael> florian: Case you talked about prob not an issue. Different issue, once things are on screen you would maybe see answer
<dael> Rossen_: Not true. a11y tree and text could get to those without moving tree
<dael> florian: Yes. Typical case screen reader not reading what's on screen. but outline of doc with hidden outline of doc when presented to user it would claim there's a section and when you try and go there it's gone
<dael> Rossen_: Point here is we're presenting informationt hat shouldn't be presented
<dael> vmpstr: Alternative is to not expose it which also exposes different information to a11y uesrs. If there are section headings that should be visible, can't be accessed through header nav which is bad
<dael> florian: Wondering about impl. a11y tree largely from box tree so you need to have a box tree which is working off some style. Isn't it?
<dael> [missed]
<dael> vmpstr: Combo of dom and box tree
<dael> Rossen_: Different view, think of it that way. Starts with dom, predomiently dom.
<dael> chrishtr: Two options are err on side of not making a mistake on display:none or err on side of expose as much as possible
<dael> fantasai: Stuff under auto is under a11y tree but other properties that cause to not be there would rmeove that. You're saying that's not possible and we need to choose everything or nothing?
<dael> chrishtr: Exactly. Not poss b/c purpose is performance. We don't want to jsut do it for a11y b/c would expose a timing difference
<dael> florian: Since would need specialized code could it only style the relevent properties for a11y tree?
<dael> vmpstr: Thought about it. number of properties isn't the cost, it's resolving all of your classes to figure out what styles. Not much cheaper to jsut apply some set of styles as opposed to full style resolution
<dael> Rossen_: Going back to chrishtr point. This is not a good idea for a11y users b/c that will effect timing
<dael> chrishtr: Partial recalc thing
<dael> Rossen_: I agree the proper solution is for purposes of a11y content-vibility:auto needs to resolve all the styles and then not effecting a11y pre-computation. That said, want to go back to point this effecting the timing. Can you tell a bit more?
<dael> chrishtr: Why the timing shouldn't be different?
<dael> Rossen_: Timing for a11y users is different already
<dael> chrishtr: One of themain concerns raised during dev of content-visibility is introducing vectors that make timing different was not okay
<dael> Rossen_: That's a worthy discussion to be had. a11y computation compared to visual is more expensive today.
<dlibby> q+
<dael> Rossen_: a11y users, to those of you who have worked with them must have seen they're more patient about getting to their content. For them it's about fidelity of getting to content, but patience is way better. Arguments about timing in favor of fidelitity is always bad for time
<dael> chrishtr: Not about patience, it's about discrimination. That's the concern raised
<dael> Rossen_: I see
<Rossen_> ack fantasai
<dlibby> q-
<dael> dlibby: I think chrishtr answered my concern. Wanted to add typically it's privacy and not exposing vectors for screen readers to be detected
<dael> Rossen_: Anyone from Mozilla here that could represent these points? Doesn't feel right to push the resolution at this point
<dael> dholbert: I wasn't part of the discussion so I don't know exactly, but could be b/c unbounded content in this that author assumes is free. If a11y has to display it could be unbounded time to process. That could be a concern. Not so much a factor longer, but unbounded time where something liek complete works of shakespeare where a a11y user has to see
<dael> Rossen_: Right, but then we're back to content-visbility:hidden that hides the content from a11y readers.
<dael> dholbert: Not sure we have great option. That's the concern with forcing a11y to style that content
<dael> Rossen_: Do you have any experiments on this?
<chrishtr> https://web.dev/content-visibility/
<chrishtr> See note about accessibility - updated last week
<dael> vmpstr: Have dev feedback for hiding. An article that said be cautios about using. Advice was to take the headers out b/c otherwise they're hidden.
<dael> vmpstr: This issue was in response to that article
<dael> chrishtr: We changed chrome behavior for more a11y, but can change back if that's the resolution
<dael> vmpstr: chrishtr that wasn't the article I talked about
<dael> chrishtr: It's linked to from that blog post
<emilio> ah, did I mess up the timezones?
<emilio> Of course
<vmpstr> https://marcysutton.com/content-visibility-accessible-semantics
<dael> Rossen_: Hearing some lines of concern. One is we don't want to penalize a11y users in a disproportionate way compared to those that don't depend on a11y tree.
<dael> Rossen_: Other concern is from PoV of what would be there will be different than what it should be had styles been computed
<dael> Rossen_: That dileima doesn't seem to be resolved. WE're trying to force a resolution to validate one or the other and we want to validate both.
<dael> fantasai: Blog post talks about putting headings inside the tree is problematic. What if we hide everything from the a11y tree but if there's headings resolve the styles on the heding and ancestors. Maybe that would allow minimal style resolution.
<dael> fantasai: You could nav to heading but hide most of it
<dael> Rossen_: A little more. It's heading, but it's links and tables and paragraphs. Everything indexable by AT today should be indexed tomorrow. AT industry has differentiatiors they're depending on
<dael> Rossen_: On top of that aria capabilities which could be referencing content-visbility subtree still need to resolve
<dael> Rossen_: We can take a whole sale don't expose or expose it the right way. Anything outside of that will be broken behavior for a11y
<dael> Rossen_: We're at top of the hour. I don't want to force resolution.
<dael> Rossen_: THis discussion will go into GH. Will hopefully prompt more discussion and we can bring back next week. Is this urgent?
<dael> vmpstr: That's fine, can wait a week

[vmpstr]

To summarize: @atanassov raised a concern that if we expose content-visibility: auto subtrees, it means exposing things that are otherwise hidden (such as display: none) and that is not ok.

Rossen_: We can take a whole sale don't expose or expose it the right way. Anything outside of that will be broken behavior for a11y

So, not exposing anything penalizes a11y users by hiding content which I don't think is a valid solution here, particularly because there is no way to force show this content in AX.

I don't know of a way that we can expose the content the right way without forcing style resolution on content-visibility auto subtrees for accessibility only. This would change timing and increase the time to produce content for accessibility users compared to non-accessibility users.

The expose-everything approach would reveal too much information, but I think the correct state can still be recovered with an appropriate use of aria labels, so I would like to not discount this approach altogether.

[flackr]

Could we expose the currently offscreen top-level content-visibility: auto elements in the accessibility tree in a way that accessibility readers would know that visiting that item would reveal some content? We could suggest that developers put appropriate title attributes on those elements so users would have context.

[vmpstr]

I don't know if there is a way in the accessibility language to express the fact this is something that will change if on-screen.

The education of putting the right headings can definitely work, but that is coupled with us hiding content by default which means that developers that don't follow best practices end up hiding more than desired from a11y users.

Alternatively the developer education can come in the form of "use aria labels if you really want to hide content" and show it by default :) (with an opposite caveat is that developers that don't follow best practices reveal more than desired to a11y users)

[flackr]

Well my proposed language would just be something that can be revealed if you "activate" it. The fact that it is activated by scrolling it into view is a detail that probably doesn't need to be expressed.

[JAWS-test]

Invisible elements (e.g. display:none) should never be included in the accessibility tree.
Offscreen elements should always be included in the accessbility tree (e.g. for element overview and quick navigation with the screen reader).
If there is a conflict between the two requirements for content-visibility: auto, content-visibility: auto must not be used.

[frivoal]

I think this case should help us think through this: in documents like social network feeds, with infinite scrolling and loading of content as you scroll, you sort of have 3 classes of elements: those are are on screen, those have have been loaded but are off-screen, those that haven't been added to the document yet, but will be once you scroll further. The later might have been fetched off the network already and be known to javascript only, or maybe they haven't even been loaded yet. Nonetheless, they are part of the conceptual document, and will eventually be visible, both by user who look at the box tree and those who navigate via the accessibility-tree. But until they are actually loaded into the DOM, they are invisible to both. For short, I'll call these off-DOM elements.

While elements with content-visibility:hidden (not auto as discussed in this issue) are in the DOM, they are closer to off-DOM elements (or display:none elements): not searchable, not tabbable, not focusable, etc. So it makes sense for them not to be reachable via the accessibility tree, as is the case for display: none elements.

Elements with content-visibility:auto are closer to off-screen elements than to off-DOM elements, as they can be searched, focused, tabbed to… So logically, they ought to be accessible through the accessibility tree as well.

The reason it's been suggested that they should be skipped is that applying styles, which is necessary to resolve things like display:none and other things that affect the accessibility tree, is expensive, and we'd rather skip that.

But I don't believe this argument holds, and we actually need to do the styling anyway, regardless of the accessibility tree situation: find-in-page also depends on display:none. So does tabbing, focusing, or selecting which are explicitely allowed on content-visibility:auto elements. So while we might not need to layout the content-visibility:auto subtree, we do need to style it anyway. and if we're going that far, there's no need to do anything unusual for the accessibility tree.

I think content-visibility: hidden-matchable, as proposed in #5595, would be the hard case, where it's much more ambiguous as to whether it's closer of off-screen or off-DOM , but this third state hasn't been accepted into css.

[vmpstr]

I agree with the above reasoning for the most part. One distinction I'd like to draw is how much of the style we need for all of the cases you mentioned:

1. Find-in-page is an explicit (uncommon) request by the user, it needs enough style to find the next match. This can either be done by forcing the style update on each content-visibility: auto element, trying to find the match, and failing to do that continuing onto the next content-visibility: auto element. (Full disclosure: Chromium forces the update on all content-visibility: auto elements, since we believe that find-in-page requiring an extra bit of rendering is acceptable, but that's an implementation detail not a requirement).
2. tabbing/focussing is also an explicit request by the user, but arguably more common. The way it's done in Chromium is to find the next potential focusable element in the DOM, update its style to ensure that it is indeed not hidden in any way. So in effect we would still update one content-visibility: auto subtree at a time.
3. For accessibility, we have to produce the full accessibility tree to an external AT, such as a screen reader, regardless of how much or how little the user intends to explore it. This means we have to update the style for every content-visibility: auto element, regardless of its distance to the viewport.

So for cases other than accessibility, we style in response to an explicit user action and we are able to only style a subset of content. In accessibility, the mere presence of accessibility tech would cause us to always update style and it has to be done on all content-visibility: auto elements.

As was mentioned in the meeting, this also potentially exposes a11y users via timing attacks. Or is the proposal to always style content-visibility: auto elements, regardless of a11y?