Skip to main content
Accessibility.com, LLC
Category: ARIA and Semantic Structure

Accessible Description

Also known as: Accessible Description (accessibility API)
Simply put

An accessible description is extra text associated with an interface element, such as a button, link, or image, that gives users of assistive technologies additional information beyond the element's short label. Where an accessible name identifies what an element is, an accessible description supplements that name with further context or instructions. Screen readers and other assistive technologies can present this description to help users understand or operate the element.

Formal definition

An accessible description is a supplementary text string exposed through the platform accessibility API and computed by the user agent from an element's markup. It complements the accessible name: the accessible name is a short label (often only 1 to 3 words) that identifies an element, while the accessible description provides additional, typically longer, context or instructions. In web content it is commonly derived from attributes such as aria-describedby (referencing other elements) or aria-description, and its computation follows the applicable name and description computation algorithm. Because descriptions are surfaced through assistive technologies, their presentation and timing can vary across screen readers and browsers, so implementations should be verified with manual and assistive technology testing rather than automated checks alone. This entry describes a technical concept and is not legal advice.

Why it matters

An accessible description gives users of assistive technologies context that a short label alone cannot convey. Where an accessible name identifies what an element is, often in just one to three words, the description supplements that name with further instructions or explanation, such as clarifying the format expected in a form field or the consequence of activating a control. For screen reader users who cannot rely on surrounding visual cues, this additional text can be the difference between confidently completing a task and abandoning it.

Because descriptions are surfaced through the platform accessibility API, their behavior depends on both the browser and the assistive technology in use. The same markup may be announced at different times, or with different verbosity, across screen readers. This variability means that supplying an accessible description in markup does not guarantee a consistent or usable experience for every user, and it reinforces why manual and assistive technology testing is necessary rather than relying on automated checks alone.

Accessible descriptions also interact with related concepts such as alternative text for images and other visual content. Providing meaningful supplementary information supports the broader goal of making interfaces understandable and operable, but no single implementation detail should be treated as a substitute for evaluating the full user experience. This entry describes a technical concept and is not legal advice.

Who it's relevant to

Accessibility Engineers and Front-End Developers
Developers implement accessible descriptions through markup such as aria-describedby or aria-description and are responsible for ensuring that the referenced text is meaningful and correctly computed. They should confirm behavior across multiple screen reader and browser combinations rather than assuming that valid markup produces a consistent announcement.
UX Designers and Content Authors
Designers and content authors decide when an element needs supplementary information beyond its short label, and they craft the wording of that description. Because the accessible name is typically only a few words, the description is where added instructions or context, including meaningful alternative text for visual content, can help users understand and operate an element.
QA and Accessibility Testers
Testers verify that accessible descriptions are actually surfaced and are useful in real assistive technology. Since presentation and timing differ across tools and automated checks catch only part of the picture, manual testing with screen readers is essential to confirm the intended experience.
Compliance Officers and Legal Counsel
Those responsible for accessibility programs should understand that supplying accessible descriptions is one technical measure among many and does not by itself guarantee an accessible experience or legal compliance. This entry is not legal advice, and organizations should consult qualified counsel regarding applicable requirements.

Inside Accessible Description

Supplementary information role
An accessible description provides additional, explanatory information about an element beyond its accessible name. Where the accessible name identifies what an element is or does, the accessible description offers extra context, clarification, or instructions.
aria-describedby
A commonly used attribute that references the ID or IDs of other element(s) whose text content becomes the accessible description. This allows visible on-screen text to serve as the description for an associated control.
aria-description
An attribute introduced in more recent ARIA specifications that allows a description string to be supplied directly on an element. Its support across browsers and assistive technologies is less consistent than aria-describedby, so implementations should be tested.
title attribute (fallback)
In some circumstances the title attribute may contribute to the accessible description, though its exposure to assistive technologies is inconsistent and it is generally not recommended as a primary mechanism.
Accessible description computation
User agents and assistive technologies derive the accessible description through a defined order of precedence, drawing from sources such as aria-describedby, aria-description, and certain host-language features, as described in the W3C Accessible Name and Description Computation specification.
Relationship to the accessibility tree
The computed accessible description is exposed through platform accessibility APIs as part of the accessibility tree, where screen readers and other assistive technologies can announce it to users.

Common questions

Answers to the questions practitioners most commonly ask about Accessible Description.

Is an accessible description the same as an accessible name?
No. An accessible name is the primary label that identifies an element (for example, the text that announces what a button does), while an accessible description provides additional, supplementary information about that element. Assistive technologies generally announce the name first and treat the description as secondary, supporting detail. The two are distinct properties in the accessibility tree, and conflating them can lead to confusing or redundant announcements.
Does adding an accessible description guarantee an element is accessible or compliant?
No. Providing an accessible description is one contributing factor, not a guarantee of accessibility or legal compliance. An element still needs an appropriate accessible name, proper roles and states, keyboard operability, and sufficient contrast, among other considerations. Automated tools can detect only a portion of potential issues, so manual testing and testing with assistive technologies are generally needed to confirm that a description is announced clearly and adds value rather than clutter.
Which techniques are commonly used to provide an accessible description?
Common approaches include the aria-describedby attribute, which points to the ID of one or more elements whose text becomes the description, and the aria-description attribute, which supplies a description string directly. For certain elements, native mechanisms such as a title attribute or a form field's help text can also contribute, though behavior varies. The specific technique should be chosen based on the element type and validated with assistive technologies, since support can differ across browser and screen reader combinations.
When should I use aria-describedby versus placing the information in the accessible name?
Use the accessible name for the essential, identifying label a user needs to understand and operate the element. Reserve the accessible description, commonly implemented with aria-describedby, for supplementary information such as formatting hints, error explanations, or additional context that supports but does not replace the name. If the information is critical to identifying the element's purpose, it generally belongs in the name rather than the description.
How can I verify that an accessible description is being announced correctly?
Inspect the element in a browser's accessibility inspector or developer tools to confirm the description appears in the accessibility tree as expected, then test with one or more screen readers to hear how and when the description is announced. Because announcement behavior can vary across browser and assistive technology combinations, testing with more than one pairing is often advisable. Automated checks may confirm that an attribute references a valid target, but they generally cannot confirm that the resulting description is meaningful or well-timed.
What are common mistakes to avoid when writing accessible descriptions?
Frequent pitfalls include duplicating the accessible name in the description, which produces repetitive announcements; referencing an aria-describedby ID that does not exist or is hidden in a way that removes its text; overloading the description with lengthy or nonessential content; and relying on the title attribute alone, whose support and discoverability can be inconsistent. Keeping descriptions concise, relevant, and verified with assistive technologies helps ensure they add value rather than noise.

Common misconceptions

The accessible description and the accessible name are the same thing.
They are distinct. The accessible name identifies or labels an element, while the accessible description provides supplementary context. Assistive technologies generally announce the name first and the description separately, and support for announcing descriptions can vary by product and configuration.
Adding an accessible description automatically makes a control understandable and accessible.
An accessible description is one mechanism that can improve clarity, but it does not by itself guarantee an accessible or usable experience. Whether it is announced depends on the assistive technology and user settings, and testing with real assistive technologies and users is needed to confirm the information is conveyed as intended.
Using the title attribute is a reliable way to provide an accessible description.
Exposure of the title attribute to assistive technologies is inconsistent, and it is not reliably available to keyboard-only or touch-screen users. Mechanisms such as aria-describedby that reference visible text are generally considered more robust.

Best practices

Use the accessible description for supplementary information only, and keep the identifying label in the accessible name rather than duplicating content between the two.
Prefer aria-describedby referencing visible on-screen text where possible, so the same information is available to all users and not hidden solely for assistive technology.
Verify that referenced IDs in aria-describedby are valid and unique, since broken or missing references will prevent the description from being computed.
Test the actual announced output across multiple screen readers and browsers, because support for description mechanisms, including aria-description, varies between assistive technologies.
Avoid relying on the title attribute as the primary source of an accessible description due to inconsistent exposure and limited availability to keyboard and touch users.
Include manual and assistive technology testing in addition to automated checks, as automated tools detect only a portion of description-related issues and cannot confirm whether the conveyed information is meaningful to users.