[css-contain-2] Clarify whether content-visibility: auto subtree elements are visible in accessibility #5857
Comments
|
It would be worth hearing from AT users and other experts on this. My sense is that the actual user impact of exposing 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 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:
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? |
https://www.theguardian.com/uk has a number of non-empty script & style elements in elements that may benefit from
I hadn't appreciated this. This makes me worry less 😄
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 |
isn't the Rotor in Voiceover an example of this? |
|
The CSS Working Group just discussed 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 |
fantasai
added
the
a11y-tracker
|
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.
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. |
|
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. |
|
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) |
|
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. |
|
Invisible elements (e.g. display:none) should never be included in the accessibility tree. |
|
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 Elements with The reason it's been suggested that they should be skipped is that applying styles, which is necessary to resolve things like 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 I think |
|
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:
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? |
|
So, if I understand correctly, if we could have something like a lazy accessibility tree, where you can compute things on demand rather than ahead of time, there would be no difference between accessibility and tabbing or search in page, but since we don't, there is a difference. Is that right?
That would be my proposal indeed, that said, I am not sure I understand the timing attack. Due to find in page (and tabbing), non-accessibility cases also sometimes need to compute the styles, so a delay caused by style computation would not necessarily be caused by usage of the accessibility tree, so it does not single out accessibility tree users.
Finding just the next one not enough, at least not to support the same behavior as currently. While it is true that the next match is highlighted in a particular way that is distinct from subsequent matches, and that even if you would normally highlight (in a different way) the rest, that doesn't matter because they are hidden anyway, you still need to find the rest:
|
That is correct. As you mentioned earlier, if you consider something like a traditional virtual-scroller where the page adds and removes elements in the stream, in part to make sure the scroller has good performance, then it is clear that the accessibility tree cannot include things that are not in the DOM. Content-visibility: auto attempts to bring similar performance to regular scrollers by skipping rendering automatically when elements are off-screen. The a11y pass though produces a different view onto the document and hands that view over to a11y technologies which allow the user to explore the document outside of UA. Here, for the most part the visual viewport is not relevant since the user can explore content which would otherwise be off-screen. If it was possible for us to provide a view into a partial document or a part of a document, with an annotation specifying that accessibility technology should request more of the document if it needs it, then that would solve the problem for sure. Unfortunately I don't think that's possible. We could expose content-visibility: auto unrendered elements as a text node saying "Please bring this into view to reveal contents" or something like that, but I don't think that would acceptable :)
I think the difference is what can be measured by script. In Chrome, the "rest of the matches" other than the first don't block rendering and are done during idle time. But in general you're right that there are times when other activities can be detected by timing. The problem, as I understand it, is that accessibility would always cause this rendering. That is, If I put something into the DOM that has content-visibility: auto and purposefully heavy style in its subtree, and measure the time it takes to render this, then more likely than not I would be able to tell whether style was processed or not and thus infer that either the user happens to have been searching for something, or that they are using accessibility technologies. I would personally be against making content-visibility: auto always process style, since this is a feature that has been designed to skip such work for off-screen content in the first place. Always styling reduces the value of the feature quite a bit. There is an argument to be made for making this off-screen content not available to accessibility, since the spec says that this content is not rendered or painted, which would imply that it is similar to visibility: hidden which I believe hides things from screen readers |
We have been looking into this more general problem (see this explainer in WICG) and have an experimental implementation in Chromium to expose this to ATs on Windows (behind a flag). We're currently working with the Narrator team in Windows to implement experimental support for this new property in order to explore the user experience in practice.
That being said, there probably is something to be said for |
|
The CSS Working Group just discussed 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: Contiuation from last week <dholbert> q+ <dael> vmpstr: Question is what do we expose to a11y when content-visibility:auto element is offscreen <dael> vmpstr: Had a bit of discussion on the issue. Don't think we have a good front runner. Wanted to continue discussion <astearns> ack dholbert <dael> dholbert: I spoke to Mozilla a11y folks and they prefer expose everything approach for offscreen content we haven't computed style for <dael> vmpstr: That would include exposing things that would otherwise have display:none? <dael> dholbert: Correct. And when we compute style they may be hidden to a11y tree <dael> vmpstr: Okay. That was initial proposal. Rossen_ raised concerns. I don't know if he is on or someone can represent <dael> Rossen_: I'm here but sounds like we're recurring back into discussion. Not sure what is the new part of discussion <dael> florian: Has been new stuff on GH. Clarifications. I think everyone agrees painting can be skipped. For styling the difficulty is for search in page or tabbing or indexing the page then you do need to style the content to find out what's available <dael> florian: For most of these you can do so lazily. <dael> florian: Ideally you could do same for a11y tree if we had a lazy build a11y tree. Could exist in theory, but not what we have. I'ts build sync. <dael> florian: Either we require you always compute the style so that we have consistent state that makes sense or we have a problem. Requiring computing the styles is more expensive then being desired <dholbert> q- <dael> vmpstr: Also dlibby mentioned that there is work to have a notion of lazy generated content in a11y content. <dael> vmpstr: Agree with florian that problem what is exposed to a11y is a view on the whole doc. Hand it off ot a11y tech and user can explore in totality <dael> vmpstr: If we do that I don't know how we solve with either not expose the content or always style which I'm against <dael> florian: You could skip painting, so not completely useless <chrishtr> q+ <dael> vmpstr: Design was to skip work and style takes a significant chunk of work so would reduce effectiveness <dael> florian: So that's a summary of where we're at in GH. Haven't figured out what to do from there <astearns> ack chrishtr <dael> chrishtr: Sounds like a11y team of chrome and mozilla have deemed current chome is okay which is to always include a11y things that are offscreen <dael> florian: include everything <dael> chrishtr: Yep <dael> florian: script, style tags, everything <dael> chrishtr: Things with a11y roles <dael> chrishtr: That are offscreen are included in a11y even though we do not yet know their styles <dael> smfr: You'll have a significant change in tree if something triggers content-visibility to render. So something would disappear <dael> chrishtr: Yep, might occur <dael> florian: Landmarks could even be a problem. But a11y tree doesn't only contain landmarks so it would contain script and style tags which are not meant for display <dael> Rossen_: I was able to catch up on thread. I think this is still very much in progress in thread. We seem to be repeating from previous call. I wanted to see besides looking for more engagement you'lre looking for <dael> vmpstr: Making progress was my hope. If engagement is what it takes, that's what I'm looking for <dael> vmpstr: We're stuck with same ideas. We have to start agreeing and I don't think we are <dael> Rossen_: Do we know if JAWS_test is from the JAWS team? The comment they added on May 17 <dael> vmpstr: I'm not sure who that is <dael> vmpstr: Comment they mentioned is if it's offscreen it should be exposed and if it's hidden it should not. This is the whole middle section of the issue. If it's offscreen it is hidden. It's unclear what to do <dael> Rossen_: Reason I asked is I think this is going to be common representation of AT devs. I'm not going to make a statement on their behalf. Having worked with them I know a lot of innovation and differentiation for ATs, especially those working behind more restrictive platform APIs, they tend to be very suseptable to these kinds of changes <dael> Rossen_: Given they don't have full access to the rendered tree this for them becomes ground. ANd if we give them something that's not representing reality we will confuse because they're building caches based on what's available. Think about it lighting up different features that should be there in presence of content. We're saying the content is there kinda sorta but we're going to say it's there. <dael> Rossen_: Reason I'm saying it we are repeating convo from last week with added clarification. Not seeing the level of engagement. I want to see what Dominick from chrome teams and a11y team says. Also waiting on [missed] to hear back from the MS AT partners <dael> vmpstr: Chrome a11y team ddi look and they were okay with what I mentioned earlier <dael> Rossen_: That's a good signal. Thank you <dael> astearns: Rossen_ can I task you to get feedback from your AT partners <dael> Rossen_: Not just our partners will have impact. But based on comments Daniel Levy is contacting them <dael> astearns: I'll take agenda tag off. Let's put it back on when we have enough to have a yea or nay vote |
|
I brought this up at our last a11y team meeting, and the general consensus was exposing offscreen content-visibility:auto content to AT's is important, and if the cost of doing that is causing some hidden content to render into the tree temporarily (until style comp), then that's a better tradeoff than not exposing the content at all. In general, we're fine with the Chrome approach. Technically, neither case fits with what AT's expect currently. The discussion on the call today seemed to indicate we're looking for a solution that maintains the tree invariants AT's expect. In that case, I think we've identified style computation as a necessary part of that solution. I'd like to flag here that doing style comp for AT's only is something we'd like to avoid because it has the potential to expose whether or not a user is using an AT. In our view, that tradeoff is also worse than rendering all content into the tree. With all that said, I think it might be worthwhile to consider modifying content-visibility such that style comp does happen, but painting doesn't -- that'd still allow UA's to optimise a bit without sacrificing AT experience. |
I am not from Freedom Scientific (JAWS). I am an accessibility expert |
|
Another possibility could be to generally include the off-screen content without computing styles, but skipping subtrees rooted in elements that are hidden by default, to reduce false false positives. Basically, everything that's head, link, meta, script, style, title,
base, basefont, datalist, noembed,
area, param,
rp,
noframes,
template,
input[type="hidden" i],
[hidden],
audio:not([controls]),
dialog:not([open])Checking against this will have a non-zero cost, but should hopefully be a lot cheaper than performing a full styling. |
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
The text was updated successfully, but these errors were encountered: