- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Jan 2021 10:41:29 +0000
- To: public-css-archive@w3.org
> 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. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5857#issuecomment-758568743 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 January 2021 10:41:30 UTC