- From: James Craig via GitHub <sysbot+gh@w3.org>
- Date: Fri, 06 Nov 2020 18:38:15 +0000
- To: public-css-archive@w3.org
> We went back and forth on this a while ago - we came to the conclusion that with the way assistive technologies (ATs) work today, it makes the most sense not to expose this content to ATs until it is visible on the page. 1. Is “We” here the TAG? Googlers? Some other group? 2. Are any of those discussions linkable? > This does mean that an AT-specific find in page feature will not be able to use the hidden-matchable functionality, unfortunately, but the alternative (exposing that content to AT, even with a "hidden" flag set) would mean that AT users would not benefit from the intended performance benefits of the feature, which are even more acute when using AT. This might depend on the implementation. If each element were exposed fully to the Accessibility tree, I agree that it would negate the perf benefit, but… Hypothetically, what if a general “find text” API were exposed in such a way that the AT could leverage the same path as the UA? VoiceOver already offloads some of its search functionality (next heading, next table, etc.) to WebKit. Perhaps a similar path could be used here. -- GitHub Notification of comment by cookiecrook Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5595#issuecomment-723236933 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 6 November 2020 18:38:21 UTC