Max Design

Published:

The Accessible Name and Description Computation 1.2 specification explains how browsers decide which parts of a page can be used to create accessible names and descriptions.

One important part of this specification defines what it means for something to be considered “hidden” during that calculation.

In other words, this section answers the question: which elements are ignored, and which can still be used, when the browser is deriving an accessible name for itself, automatically.

The steps below are plain-English translations of the specification, so you can clearly see which elements are treated as hidden and which ones still count toward the accessible name.

Two ways accessible names are created

Before looking at what “hidden” means, it helps to understand how accessible names are usually created.

In practice, there are two ways a browser can determine an accessible name or description.

1. Implicit name computation (the default)

For almost every element on a page, the browser works out the accessible name automatically.

It does this by:

This is called implicit name computation, and it is how accessible names are created for the vast majority of elements.

Unless an author explicitly says otherwise, this is the path the browser uses.

2. Explicit name computation (the exception)

In some cases, the author can override this automatic process.

Attributes like aria-labelledby and aria-describedby allow the author to explicitly point to other elements and say:

“Use the text from these elements as the name or description.”

This is called explicit name computation.

It is far less common than implicit computation, but when it is used, it changes how name calculation works in important ways.

Why this distinction matters here

The rules that define what is considered “hidden” apply to implicit name computation.

They describe which elements are ignored when the browser is automatically discovering text.

These rules apply to almost everything, except cases where the author has explicitly defined relationships using aria-labelledby or aria-describedby.

With that in mind, we can now look at the four categories the specification uses to define “hidden”.

1. Hidden via CSS

This includes:

These properties are considered hidden.

Elements styled this way are not rendered, do not take up space, and do not appear in the accessibility tree.

Verdict:

They cannot contribute to accessible names or descriptions when names are computed implicitly.

2. Hidden via SVG or visual transparency

This includes:

These techniques are not considered hidden.

Even though the element is visually invisible, it is still present in the layout, in the DOM, and in the accessibility tree, unless it is explicitly removed by other means. Text may still be selectable or copyable.

Verdict:

They can contribute to accessible names and descriptions.

3. Hidden via ARIA

This includes:

This attribute is considered hidden.

The author has explicitly instructed the browser to exclude the element from accessibility APIs. As a result, the element is removed from the accessibility tree.

Verdict:

It cannot contribute to accessible names or descriptions through implicit name computation.

4. Positioned off-screen or visually covered

These elements remain in the accessibility tree even if they are not visible on screen.

If an element is moved far off-screen or visually obscured by another element, it still exists in the DOM and in the accessibility tree. This includes common patterns like “visually hidden but accessible” text used for contextual labelling or instructions.

These elements are not considered hidden by the specification.

Verdict:

They can contribute to accessible names and descriptions.

Why aria-labelledby and aria-describedby are different

aria-labelledby and aria-describedby work in a different way.

They do not ask the browser to discover text automatically. Instead, the author explicitly tells the browser which elements to use by referencing their IDs.

When these attributes are present, the browser:

This process happens even if the referenced elements are hidden, not rendered, or otherwise excluded from the accessibility tree.

Because of this, the “hidden” rules described earlier do not apply in the same way. Those rules are about skipping hidden content during automatic traversal. aria-labelledby and aria-describedby intentionally bypass traversal altogether.

How this makes sense in practice

The confusion usually comes from treating accessible name computation as a single process. In reality, there are two distinct paths.

Implicit computation

The browser derives a name from an element’s own content. Hidden content is skipped.

Explicit computation

The author provides exact references using aria-labelledby or aria-describedby. Referenced content is used, even if it is hidden.

The specification’s “hidden” note is correct for the first case, but it does not apply cleanly to the second unless this distinction is understood.

This is why text from elements that are hidden, marked with aria-hidden="true", or styled with display: none can still contribute to an accessible name or description when referenced explicitly.

This is not a bug or an exception. It is how explicit relationships are designed to work, and why they override the visibility rules used during automatic name discovery by design.