- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Mar 2021 17:01:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-2] Clarify whether content-visibility: auto subtree elements are visible in accessibility`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-contain-2] Clarify whether content-visibility: auto subtree elements are visible in accessibility<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5857<br> <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<br> <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<br> <dael> vmpstr: They would be essentially visibile in a11y. Offscreen elements in subtree of content-visbility:auto are visibile in a11y.<br> <dael> Rossen_: Which is the case with visbility, but not display:none<br> <dael> Rossen_: Sounds reasonable. Any other opinions?<br> <dael> florian: I think it's different than visbility:hidden. Not all elements in subtree are accessible. In this case they would all be<br> <dael> chrishtr: Yes, would make all visbilie even if display:none ancestor<br> <dael> vmpstr: aria label would be respected so can hide<br> <dael> fantasai: Seems weird<br> <dael> Rossen_: Bigger issue. If could to disable hammer of display:none which does nothing, if we distablize that promise different convo<br> <dael> florian: WE don't want to ignore display:none, but we're ignoring styles and display:none is a style<br> <dael> fantasai: But if treating as shown you have to look at styles<br> <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<br> <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<br> <fantasai> +1 to Rossen<br> <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<br> <dael> Rossen_: Breaking display:none for a11y or css is bad<br> <dael> florian: Case you talked about prob not an issue. Different issue, once things are on screen you would maybe see answer<br> <dael> Rossen_: Not true. a11y tree and text could get to those without moving tree<br> <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<br> <dael> Rossen_: Point here is we're presenting informationt hat shouldn't be presented<br> <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<br> <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?<br> <dael> [missed]<br> <dael> vmpstr: Combo of dom and box tree<br> <dael> Rossen_: Different view, think of it that way. Starts with dom, predomiently dom.<br> <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<br> <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?<br> <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<br> <dael> florian: Since would need specialized code could it only style the relevent properties for a11y tree?<br> <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<br> <dael> Rossen_: Going back to chrishtr point. This is not a good idea for a11y users b/c that will effect timing<br> <dael> chrishtr: Partial recalc thing<br> <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?<br> <dael> chrishtr: Why the timing shouldn't be different?<br> <dael> Rossen_: Timing for a11y users is different already<br> <dael> chrishtr: One of themain concerns raised during dev of content-visibility is introducing vectors that make timing different was not okay<br> <dael> Rossen_: That's a worthy discussion to be had. a11y computation compared to visual is more expensive today.<br> <dlibby> q+<br> <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<br> <dael> chrishtr: Not about patience, it's about discrimination. That's the concern raised<br> <dael> Rossen_: I see<br> <Rossen_> ack fantasai<br> <dlibby> q-<br> <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<br> <dael> Rossen_: Anyone from Mozilla here that could represent these points? Doesn't feel right to push the resolution at this point<br> <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<br> <dael> Rossen_: Right, but then we're back to content-visbility:hidden that hides the content from a11y readers.<br> <dael> dholbert: Not sure we have great option. That's the concern with forcing a11y to style that content<br> <dael> Rossen_: Do you have any experiments on this?<br> <chrishtr> https://web.dev/content-visibility/<br> <chrishtr> See note about accessibility - updated last week<br> <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.<br> <dael> vmpstr: This issue was in response to that article<br> <dael> chrishtr: We changed chrome behavior for more a11y, but can change back if that's the resolution<br> <dael> vmpstr: chrishtr that wasn't the article I talked about<br> <dael> chrishtr: It's linked to from that blog post<br> <emilio> ah, did I mess up the timezones?<br> <emilio> Of course<br> <vmpstr> https://marcysutton.com/content-visibility-accessible-semantics<br> <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.<br> <dael> Rossen_: Other concern is from PoV of what would be there will be different than what it should be had styles been computed<br> <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.<br> <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.<br> <dael> fantasai: You could nav to heading but hide most of it<br> <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<br> <dael> Rossen_: On top of that aria capabilities which could be referencing content-visbility subtree still need to resolve<br> <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<br> <dael> Rossen_: We're at top of the hour. I don't want to force resolution.<br> <dael> Rossen_: THis discussion will go into GH. Will hopefully prompt more discussion and we can bring back next week. Is this urgent?<br> <dael> vmpstr: That's fine, can wait a week<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5857#issuecomment-801250404 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 March 2021 17:01:25 UTC