Unlocking Hidden Content: An Introduction to hidden='until-found'

#html #wcag #a11y #css

The value 'until-found' for the hidden HTML attribute is supported by Chrome and Firefox at the time of writing. Also, support has been added to Safari TP and is expected to land this year.

Before we look at the 'until-found' value specifically, let's quickly recap what the hidden attribute does when it's added to an HTML element. This attribute tells the browser that the element's contents are not currently relevant and should not be presented to the user. Commonly, the browser will then apply the CSS style display: none, totally hiding the element. In contrast, when hidden='until-found' is applied, this tells the browser that the contents are relevant, but should not be visible initially. Despite being visually hidden, its content remains discoverable by the browser (although not in the DOM and not in the accessibility tree). So, the browser's "Find in Page" and deep linking functionality will still work.

<div hidden>
 <p>Hello, I'm totally hidden and cannot be found.</p>
</div>
<div hidden="until-found">
 <p>Hello, I'm invisible, but can still be found!</p>
</div>

When a user searches for and finds text within such an element, the browser automatically reveals it and scrolls it into view. This feature improves initial page load times by deferring content rendering while maintaining a seamless search experience. It's ideal for progressively disclosing content like collapsible sections that users might search for.

In a nutshell, content within an element that has the hidden attribute (or CSS display: none) will not be found by the browser and cannot be deep linked to. Whereas content within an element with hidden='until-found' is discoverable and can be linked to.

Interactive Components

Hidden content is a fundamental feature of interactive components such as accordions, carousels, and tabbed interfaces. These popular UI patterns offer several advantages including:

Space Optimisation: Simply stacking all content vertically can lead to extremely long, overwhelming pages that require excessive scrolling, making them hard to navigate and boring. These components allow you to condense content by showing only a portion of it at a time.
Well-Structured Content: Monolithic blocks of text or images can be difficult for users to scan, understand, and navigate. Key information might get lost. Grouping related information into a collapsible section helps provide a clear, logical structure for content, making it easier for users to find what they're looking for.
Enhanced User Experience: Long, static pages can be boring and increase cognitive load, which can lead to user fatigue or abandonment. Interactive components and progressive disclosure make the page feel more dynamic, less daunting, and quite frankly, more 'fun'.
Aesthetic Appeal: These components contribute to a cleaner aesthetic. They can make a page look less cluttered and more professional.

The Problem

Let's take a look at what problems hidden='until-found' solves.

Despite the benefits of interactive components, traditional hidden content presents a significant accessibility challenge, it's simply not discoverable by browsers.

This invisibility creates a disproportionate burden for several user groups. For example, visually impaired users, who often rely on screen readers and the browser's "Find in Page" functionality, are particularly affected.

Similarly, users with motor control issues face additional obstacles when navigating interactive components that hide content.

When content is hidden using conventional methods, search functions cannot locate relevant information severely limiting these users' ability to find what they need.

These limitations create a fundamental tension: the very components designed to improve user experience for some can simultaneously erect barriers for others. This is precisely the problem that hidden='until-found' was designed to solve.

Implementation Example

In the following tabbed component example, which is implemented using hidden='until-found', we can see how content becomes both searchable and linkable.

Developer notes

In the above example, instead of using a classname (commonly using the CSS display: none property), we are using the hidden='until-found' attribute. When content is 'found' by the browser, it dispatches a JavaScript event called beforematch, and the content is shown. In the case of a tab component, we can't have two tabs visible at the same time, so we listen for the beforematch event, and when it fires, we need to manually hide whichever tab is not required.

There is one obvious difference between hidden and hidden='until-found' any block-level styles on the element like border or padding won't be visible when the hidden attribute is used, but WILL be when hidden='until-found' is applied. This is because the browser will typically only hide the element's contents and not the element itself. Not a big deal, but still something to bear in mind if you are going to be working with an existing codebase.

Top comments (3)

david duymelinck • Sep 10

It feels like a weird way to fix the problem. As I understand from this article the reason for hidden="until-found" is because of the content-visibility style.
A logical solution for me would be to add the until-found value to the content-visibility style.
The hidden attribute, for me, is to hide the content from the DOM, while content-visibility: hidden gives the sign that the element shouldn't be rendered.
Mixing the two concerns feels wrong.

patrick clancey • Sep 11 • Edited

That's an interesting perspective! I understand your point about mixing concerns, but I think the attribute implementation actually provides clearer separation and several practical advantages:

State Management: When the browser reveals content, it automatically removes the hidden attribute. This creates a clear, inspectable state change that's visible in the DOM—making it much easier to track an element's current status than with a CSS-only approach.
Selector Targeting: This state change enables straightforward CSS targeting like .my-tab-panel:not([hidden]) { padding: 1rem; }. With a pure CSS solution, determining whether content was revealed by search would be much more complex, probably requiring JS.
Performance Independence: The attribute method works even before CSS is downloaded or if CSS fails to load, ensuring the core functionality remains intact regardless of styling issues.
Semantic Clarity: hidden is fundamentally about whether content should be presented to users, which aligns perfectly with HTML's role. The until-found value simply modifies how that hiding behaves, rather than mixing unrelated concerns.
Accessibility Integration: This approach ties directly into the browser's native search and accessibility systems at the DOM level, which is more appropriate than handling it through the presentation layer (CSS).

While content-visibility: hidden is about rendering optimisation, hidden="until-found" is about content discoverability and progressive disclosure—different concerns that warrant different implementations.

david duymelinck • Sep 11 • Edited

While I can see the logic in your points. My second train of thought was if they can add hidden="until-found", why didn't they add hidden="from-render" instead of a adding a css style?
I read a little more about the differences, and I was wrong that hidden removed the content from the DOM. As I understand it content-visibility was created for performance and the only significant change in behaviour with hidden is that the container is rendered.

Another confusing part is that there is a visibility style. Why is visibility: collapse not enough?
And why are there SVG tags that have an visibility attribute?

My comment is more about are they thinking about the whole system or are they only thinking about one feature at a time?