Why you shouldn't use content-visibility (yet)

Published on by Yakim van Zuijlen.

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:

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.

The 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.

The 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 content-visibility: auto.

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.

Further reading