You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the content-visibility CSS property is set to hidden, the element and its content are not rendered. Despite this, browser implementations handle accessibility exposure differently:
WebKit: even when the property is set to hidden, WebKit continues to expose the content in the acc tree. This means that assistive technologies, such as VoiceOver, still recognize and announce the hidden content.
Chromium and Gecko: in Chromium and Gecko, content with content-visibility: hidden is removed from the acc tree, making it not available to assistive technologies.
content-visibility: hidden improves on both of these options. Because the contents are skipped, the user agent isn’t spending time on them when they’re not active. They’re also not visible to screen readers, find-in-page, and other tools. And because user agents should preserve previous styling/layout work if possible, if the view was displayed before, re-rendering it might be very fast.
The expectation is that this content should not appear in the accessibility tree.
I tried to explore possible workarounds to create a WPT test checking for ignored nodes in the accessibility tree using roles and labels, but the behavior is inconsistent:
Chromium returns "none" for the comp role and an empty string for the comp label on ignored nodes
WebKit throws an error for both get_computed_label and get_computed_role on ignored nodes:
When the content-visibility CSS property is set to hidden, the element and its content are not rendered. Despite this, browser implementations handle accessibility exposure differently:
From CSS Containment Module Level 2 specs:
The expectation is that this content should not appear in the accessibility tree.
I tried to explore possible workarounds to create a WPT test checking for ignored nodes in the accessibility tree using roles and labels, but the behavior is inconsistent:
It seems like there’s no reliable way to test for this at the moment
Note: also the value "auto" is inconsistently managed; however, this issue is currently pending w3c/core-aam#243.
The text was updated successfully, but these errors were encountered: