The new CSS property
content-visibility is being developed right now. It's part of the CSS Containment Module Level 2 (latest draft). Here's what it does:
"The content-visibility property controls whether or not an element renders its contents at all, along with forcing a strong set of containments, allowing user agents to potentially omit large swathes of layout and rendering work until it becomes needed."
Its main goal is to improve initial load times by skipping the rendering of offscreen content. It's been implemented in Chrome 85 and is being prototyped in Firefox. The spec still has issues and unknowns though which disproportionately affect people who use screen readers.
First, let's go over what we do know. The
content-visibility property can have either one of these values:
- Visible: "No effect. The element’s contents are laid out and rendered as normal."
- Hidden: "The element skips its contents. The skipped contents must not be accessible to user-agent features, such as find-in-page, tab-order navigation, etc., nor be selectable or focusable."
- Auto: "The element turns on layout containment, style containment, and paint containment. If the element is not relevant to the user, it also skips its contents. Unlike hidden, the skipped contents must still be available as normal to user-agent features such as find-in-page, tab order navigation, etc., and must be focusable and selectable as normal."
My first reaction when learning about this property is why it's needed. Managing which elements need to be rendered at any given point seems like a task best suited to the browser engine. I don't have much knowledge about browser engines though, so there are probably legitimate use-cases for
content-visibility that I am missing that can't be solved by the browser itself. But I've heard others share the same sentiment of wanting this to be solved on the browser side instead.
I want to mention Steve Faulkner's great article with live demos showing how the current implementation of
content-visibility works in Chrome. It sometimes works in unexpected ways.
Let's go over the values. The
visible value acts like a reset. Nothing special here.
auto value seems reasonable. It has the compromise that the skipped contents must still be available for user-agent features (like find in page, tab navigation, focus, etc.). This is important, and a good trade-off. It mentions that if the element is not relevant to the user, it should also skip its contents. There is however no mention in the definition of that term on how it should affect the accessibility tree.
hidden value gives a lot of power and responsibility to authors. It skips all the rendering steps of an element and it's contents (layout, style, paint, and size). This means that it won't be available to assistive technologies either. Assistive technologies rely heavily on semantics and full access to all the content on a page. While the viewport is the main way of browsing a website for many people, other people might be using assistive technologies like screen readers that navigate the page's content beyond the bounds of the viewport.
The problem with putting
content-visability on elements outside the viewport is that they won't be usable by assistive technologies. Marcy Sutton wrote a great article a while back about Content-visibility and Accessible Semantics in which she recommends to keep headings and landmark elements outside of regions styled with
So, just to put that in perspective: you shouldn't use
content-visibility on any elements that contain semantics or interactivity like links, buttons, headings, landmarks, focus, tab-order, or selection. How many elements pass that criteria on a typical website, where almost every section has at least some interactivity? Especially single-page apps, which this spec is focussing on.
This is all presuming that authors have perfect knowledge of the implications of this property. In reality I am less optimistic. I fear that in a lot of cases the performance improvements will be implemented without consideration for accessibility. Even when the negative impact on accessibility vastly overshadows any positive performance improvements.
I'll be keeping an eye out for future changes to the spec and browser implementation (prototypes) that address these issues.
- CSS Containment Module Level 2 - W3C Working Draft
- CSS Containment Module Level 2 - W3C Editor's Draft
- content-visibility - MDN
- Short note on content-visibility: hidden - Steve Faulkner
- Content-visibility and Accessible Semantics - Marcy Sutton
- Twitter thread on Chrome's implementation issues
- Issue #5857: [css-contain-2] Clarify whether content-visibility: auto subtree elements are visible in accessibility