[css-contain] add new value where content is visually hidden, but exposed to accessibility tree

[Schepp]

Spec: CSS Containment Module Level 2

So far, content-visibility knows three possible values: visible, auto and hidden. While they all do solve certain problems developers face in regards to showing and hiding, while playing well with other interaction concepts, one pretty prominent "cowpath" hasn't yet been paved and I'd see this CSS property as being the right place to do so: Hiding elements from sighted users while at the same time exposing them in the accessibility tree for AT users.

To solve this use case today, developers reach out for CSS utility classes of the likes of sr-only or visually-hidden, which usually look like this:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border-width: 0;
}

(example taken from TailwindCSS)

It would be wonderful if content-visibility could be equipped with one more value, which would cater to the above need and make use of such CSS utility classes absolete.

/edit: Web Alamanac 2022 sees 15% of the pages analyzed using it.

[yatil]

Thumbs down for this suggestion. Content hidden from screen but available to assistive technologies (not only to screen readers) is a hack that needs to be resolved, not enshrined, as @scottaohara so eloquently put it. Hidden content seems great when it is built in, but through updates by (visual) developers the content is often out of sync. And it also can be an obstacle to screen reader users who see the screen. Making it easier for developers to employ such a hack will make these issues even more likely. Content that is not visible on the screen, gets out of sync and is misleading already accounts for a sizeable percentage of accessibility issues.

Also, these practices stem from a time when ARIA was much less available and so hidden text used to be the only option. Now ARIA labels etc. can be used instead in most, if not all, times when hidden additional information is needed.

Don’t make the lives of testers and especially disabled people harder by making it easier for developers to use these kinds of non-best practices.

[pepelsbey]

One of the reasons to have such a property or value could be that some browsers still don’t translate ARIA labels (built-in Firefox translate, for example). Although the situation has improved a lot for built-in tools (both Safari and Chrome are fine), it might not be the case for browser extensions or some other translation tools.

Another reason would be when you don’t have some title or text in the design that’s considered obvious and got removed. But you still would like to put the title “Articles” on top of the archive for a better heading structure.

By the way, there’s already a similar issue: Create a display property value for visually hiding an element while making it available for AT.

[Loirooriol]

This sounds somewhat like box-suppress: hide https://www.w3.org/TR/2015/WD-css-display-3-20151015/#valdef-box-suppress-hide

[Loirooriol]

Is there a reason for tying this to containment instead of display? Do you want to hide only the content or also borders and such?

[johannesodland]

There is another use case for an additional value here:

The premise for auto is that the user agent knows when an element is relevant for the user. That is not always true, and it would be great if authors were able to tell the user agent when it is relevant or not.

If an element is in the viewport it is considered to be relevant, and is its content is not skipped, while It could be in the viewport, only obscured.

Scroll-driven animations opens up new opportunities. As an example, we could break down an article in “pages” and stack them on top of each other visually. As the user scrolls we could animate each page off the top of the stack, as if they were shoving the paper off the stack.

In this example every element on the page would be in the viewport, but only a few on the top would be relevant to the user.

Authors should be able to tell the user agent to skip that content, while ensuring that the content is available as usual to user agent features such as find-in-page and so on.

[Loirooriol]

Then you can add or remove content-visibility:hidden with JS according to your needs.

[johannesodland]

Then you can add or remove content-visibility:hidden with JS according to your needs.

Then that content would not be available to the user agent as usual, defeating the point. It should be searchable, focusable and exposed to the accessibility tree similar to how it would be if it was outside the viewport in a different layout.

[Loirooriol]

Sounds like hidden-matchable (#5595)

[tabatkins]

One of the reasons to have such a property or value could be that some browsers still don’t translate ARIA labels (built-in Firefox translate, for example). Although the situation has improved a lot for built-in tools (both Safari and Chrome are fine), it might not be the case for browser extensions or some other translation tools.

Note that, in general, adding a feature to work around a bug isn't valuable; we can just fix the bug instead, and reduce the proliferation of features.

[pepelsbey]

Note that, in general, adding a feature to work around a bug isn't valuable; we can just fix the bug instead, and reduce the proliferation of features.

Yes, that makes a lot of sense. Unfortunately, it’s not the only reason. Also, it’s not just browser engines, but multiple translation tools. I’m not sure that would be possible to achieve and maintain.

[Que-tin]

I feel like I've seen a draft like this, with the same discussions before, but I can't find it.