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
The content-visibility CSS property offers developers a powerful way to optimize rendering performance by controlling whether an element's content is rendered and laid out. However, its behavior in terms of accessibility differs significantly between browsers, particularly when the property is set to hidden or, even more when set to auto.
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.
When the content-visibility CSS porperty is set to auto, the behavior becomes more complex, since accessibility results vary significantly between browsers:
WebKit apparently exposes all content in the acc tree (at least looking at the inspector), regardless of its visibility in the viewport. However, when using the VoiceOver rotor, some content is announced while other content is ignored, seemingly without a clear logical pattern. For instance, landmarks are exposed, but headings are only announced when they are within the viewport. It appears that content that is not visible is still exposed, but without an acc name. This likely explains why headings are skipped, while links and buttons are announced, even though they lack an accessibility name.
Chromium exposes all content to assistive technologies, even if it is outside the viewport. In the following screenshots, it is highlighted that when navigating using the rotor, all elements are properly exposed, including those not in the viewport.
Gecko behaves similarly to WebKit by limiting accessibility exposure to only the elements currently visible within the viewport. In the acc tree, roles are assigned to elements outside the viewport, but their accessibility names are left empty. This differs from WebKit, which displays accessibility names in the inspector even for off-screen elements. Using the rotor instead, the behaviour is consistent with WebKit, exposing the elements without acc name.
The text was updated successfully, but these errors were encountered:
The
content-visibility
CSS property offers developers a powerful way to optimize rendering performance by controlling whether an element's content is rendered and laid out. However, its behavior in terms of accessibility differs significantly between browsers, particularly when the property is set to hidden or, even more when set to auto.When the
content-visibility
CSS property is set tohidden
, 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.When the
content-visibility
CSS porperty is set toauto
, the behavior becomes more complex, since accessibility results vary significantly between browsers:WebKit apparently exposes all content in the acc tree (at least looking at the inspector), regardless of its visibility in the viewport. However, when using the VoiceOver rotor, some content is announced while other content is ignored, seemingly without a clear logical pattern. For instance, landmarks are exposed, but headings are only announced when they are within the viewport. It appears that content that is not visible is still exposed, but without an acc name. This likely explains why headings are skipped, while links and buttons are announced, even though they lack an accessibility name.
Chromium exposes all content to assistive technologies, even if it is outside the viewport. In the following screenshots, it is highlighted that when navigating using the rotor, all elements are properly exposed, including those not in the viewport.
Gecko behaves similarly to WebKit by limiting accessibility exposure to only the elements currently visible within the viewport. In the acc tree, roles are assigned to elements outside the viewport, but their accessibility names are left empty. This differs from WebKit, which displays accessibility names in the inspector even for off-screen elements. Using the rotor instead, the behaviour is consistent with WebKit, exposing the elements without acc name.
The text was updated successfully, but these errors were encountered: