- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Mar 2021 16:19:07 +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: Contiuation from last week<br> <dholbert> q+<br> <dael> vmpstr: Question is what do we expose to a11y when content-visibility:auto element is offscreen<br> <dael> vmpstr: Had a bit of discussion on the issue. Don't think we have a good front runner. Wanted to continue discussion<br> <astearns> ack dholbert<br> <dael> dholbert: I spoke to Mozilla a11y folks and they prefer expose everything approach for offscreen content we haven't computed style for<br> <dael> vmpstr: That would include exposing things that would otherwise have display:none?<br> <dael> dholbert: Correct. And when we compute style they may be hidden to a11y tree<br> <dael> vmpstr: Okay. That was initial proposal. Rossen_ raised concerns. I don't know if he is on or someone can represent<br> <dael> Rossen_: I'm here but sounds like we're recurring back into discussion. Not sure what is the new part of discussion<br> <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<br> <dael> florian: For most of these you can do so lazily.<br> <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.<br> <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<br> <dholbert> q-<br> <dael> vmpstr: Also dlibby mentioned that there is work to have a notion of lazy generated content in a11y content.<br> <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<br> <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<br> <dael> florian: You could skip painting, so not completely useless<br> <chrishtr> q+<br> <dael> vmpstr: Design was to skip work and style takes a significant chunk of work so would reduce effectiveness<br> <dael> florian: So that's a summary of where we're at in GH. Haven't figured out what to do from there<br> <astearns> ack chrishtr<br> <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<br> <dael> florian: include everything<br> <dael> chrishtr: Yep<br> <dael> florian: script, style tags, everything<br> <dael> chrishtr: Things with a11y roles<br> <dael> chrishtr: That are offscreen are included in a11y even though we do not yet know their styles<br> <dael> smfr: You'll have a significant change in tree if something triggers content-visibility to render. So something would disappear<br> <dael> chrishtr: Yep, might occur<br> <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<br> <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<br> <dael> vmpstr: Making progress was my hope. If engagement is what it takes, that's what I'm looking for<br> <dael> vmpstr: We're stuck with same ideas. We have to start agreeing and I don't think we are<br> <dael> Rossen_: Do we know if JAWS_test is from the JAWS team? The comment they added on May 17<br> <dael> vmpstr: I'm not sure who that is<br> <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<br> <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<br> <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.<br> <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<br> <dael> vmpstr: Chrome a11y team ddi look and they were okay with what I mentioned earlier<br> <dael> Rossen_: That's a good signal. Thank you<br> <dael> astearns: Rossen_ can I task you to get feedback from your AT partners<br> <dael> Rossen_: Not just our partners will have impact. But based on comments Daniel Levy is contacting them<br> <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<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-805964613 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 March 2021 16:19:09 UTC