Accessible Description

Every interactive element on a web page has an accessible name — the primary label that identifies it to assistive technology users. The accessible description serves as a companion to that name, offering extra details, hints, or instructions that help users understand an element's purpose or expected behavior more fully. While the accessible name answers "what is this?", the accessible description answers "what else should I know about this?"

The accessible description is computed by the browser using a well-defined algorithm specified in the WAI-ARIA Accessible Name and Description Computation. Multiple HTML and ARIA mechanisms can supply a description, and the browser resolves them in a specific order of precedence. Assistive technologies like screen readers typically announce the accessible name first, followed by the role, and then the accessible description — often after a brief pause — giving users a layered understanding of the element.

Why accessible description matters

For sighted users, visual cues such as helper text near a form field, tooltips, or contextual icons provide additional guidance. Users of assistive technologies don't always perceive these visual relationships automatically. The accessible description bridges that gap by programmatically associating supplementary information with the element it relates to.

Without a proper accessible description:

• Screen reader users may miss critical instructions like password requirements or input format expectations.
• Error messages linked to form fields may not be announced in context, forcing users to search the page for relevant feedback.
• Complex widgets like dialogs or custom controls lack the contextual information that makes them usable.

Accessible descriptions benefit everyone who relies on assistive technology, including people who are blind, have low vision, or have cognitive disabilities that make additional context helpful.

How accessible description works

The computation algorithm

The browser determines an element's accessible description by checking several sources in order of priority:

1. aria-describedby — References one or more elements by their id whose text content becomes the description.
2. aria-description — A string attribute that directly sets the description (introduced in ARIA 1.3, with growing browser support).
3. title attribute — Used as a fallback description if no other description source is present and the title is not already being used as the accessible name.

If the first applicable source provides a value, the algorithm stops there. This means aria-describedby takes precedence over aria-description, which takes precedence over title.

Difference from accessible name

It's important to understand that the accessible name and accessible description are separate concepts. The accessible name is the primary identifier (set via <label>, aria-label, aria-labelledby, or native text content). The accessible description is supplementary. Screen readers announce them differently — the name immediately, the description as secondary information. Mixing them up (e.g., putting critical identifying information only in the description) can make elements harder to find and interact with.

When to use a description

Use an accessible description when an element's name alone isn't sufficient. Common scenarios include:

• Form fields that need format hints or validation instructions.
• Buttons or links whose names are ambiguous without context (e.g., multiple "Delete" buttons on a page).
• Dialog windows that benefit from a summary of their purpose.
• Icons or controls where a brief name is supplemented by a longer explanation.

Avoid overloading the description with excessive text. Screen reader users hear it read aloud every time they encounter the element, so keep it concise and genuinely helpful.

Code examples

Bad example — helper text not programmatically associated

In this example, the helper text sits near the input visually but has no programmatic relationship to it. A screen reader will announce only "Password" with no additional context.

<label for="pw">Password</label>
<input type="password" id="pw">
<p>Must be at least 8 characters with one number and one symbol.</p>

Good example — using aria-describedby

Here the helper text is linked to the input via aria-describedby. A screen reader will announce the field name first, then read the description.

<label for="pw">Password</label>
<input type="password" id="pw" aria-describedby="pw-hint">
<p id="pw-hint">Must be at least 8 characters with one number and one symbol.</p>

Good example — using aria-description

When there is no visible helper text element to reference, aria-description can provide the description directly as a string.

<label for="username">Username</label>
<input type="text" id="username" aria-description="Your username is case-sensitive and cannot be changed later.">

Good example — combining multiple description sources with aria-describedby

You can reference multiple id values in aria-describedby, separated by spaces. The text content of each referenced element is concatenated in order.

<label for="email">Email address</label>
<input type="email" id="email" aria-describedby="email-hint email-error">
<p id="email-hint">We'll use this to send your order confirmation.</p>
<p id="email-error" role="alert">Please enter a valid email address.</p>

Bad example — relying solely on title for important instructions

The title attribute is unreliable as a primary description mechanism. Many screen readers ignore or deprioritize it, and it is invisible to keyboard-only users and mobile users.

<label for="dob">Date of birth</label>
<input type="text" id="dob" title="Enter in MM/DD/YYYY format">

Good example — replacing title with visible, linked text

<label for="dob">Date of birth</label>
<input type="text" id="dob" aria-describedby="dob-format">
<span id="dob-format">Enter in MM/DD/YYYY format</span>

By using aria-describedby with visible text, you ensure the description is available to all users — those using screen readers, those navigating by keyboard, and those who benefit from reading the instructions on screen.