- From: vmpstr via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Mar 2021 15:00:18 +0000
- To: public-css-archive@w3.org
> 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 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 :) > Finding just the next one not enough, at least not to support the same behavior as currently. 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 -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5857#issuecomment-804130547 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 22 March 2021 15:00:20 UTC