Accessible Name and Description

7 minute read

Last updated: Sep 19, 2026

Accessible Name and Description help assistive tech. They identify and explain page elements. This includes buttons, links, form fields, tables, and regions. An accessible name is the element’s title. An accessible description gives more details about the element.

Overview

An accessible name is the name of something on a page used by assistive technologies such as screen readers. An accessible name usually appears as a short title of one to three words, and an accessible description might provide instructions for completing a form field. For example, a button written as <button>Exit</button> has “Exit” as its accessible name, so a screen reader can say something like “Exit, button.”

Everything that requires interaction or has a meaningful presence on the page should have an accessible name because. This is needed for accessibility standards, like the Web Content Accessibility Guidelines (WCAG). Browsers look for this name in a specific order:

First, they generally look at aria-labelledby.
If aria-labelledby is not present, they look at aria-label,
Then, native HTML methods such as <label>, <legend>, and <caption>,
Followed by the element’s own visible text or content, and
Finally, fallback information such as titles or placeholders when appropriate.

Other common ways to provide a name include:

Visible text inside an element, such as <button>Exit</button>,
aria-label, such as <button aria-label="Close">X</button>, or
aria-labelledby to take the name from another element, such as <h2 id="profile">Your Profile</h2> with aria-labelledby="profile".

Form fields can use <label>, groups of fields can use <legend>, and tables and figures can use <caption> and <figcaption>.

An accessible description gives extra information about an element after its name has been provided. For example, a password field may have the name “Password” and the description “Your password must be at least 8 characters long.” The most common way to provide this extra information is aria-describedby, which connects an element to another piece of text by using that text’s ID, such as <input id="password" aria-describedby="password-help"> together with <p id="password-help">Your password must be at least 8 characters long</p>.

Aria-description can also provide a description directly, such as <input aria-description="Password must contain at least 8 characters">.

You can learn more about ARIA in Introduction to ARIA (Ta11y).

Captions provide additional details about tables and figures. The title can also provide a basic description.

The goal is to make sure that both the name and any important extra information are available to everyone, whether they are looking at the page or using assistive technology.

Who is Helped

Correct accessible naming benefits a wide range of people and contexts:

Screen reader users, like those who are blind, have low vision, or have a cognitive disability: They rely on accessible names and descriptions. This helps them understand the purpose of buttons, links, or fields.
Voice control and speech input users, who may have motor or vision disabilities: They use accessible names as commands to interact with elements. For example, a button named “Search” via aria-label will be identified by the Voice control software easily when the user says, “Click Search”.
Screen magnifier users with low vision: These users benefit from concise names and clear labels. Visible text is easier to find in zoomed, cropped views than hidden or overly long names.
Users with cognitive or learning disabilities: A clear name helps. A simple description makes webpage elements easy to understand. This way, they won’t have to guess or waste time figuring out what everything means.

Guidelines

It is important to remember that an accessible name is not the same as a visual label. A sighted user can see a page and understand an element’s purpose from nearby text. But a screen reader user might miss information unless the code links the text correctly to the element. This means that simply displaying text on the screen is not always enough. The name must be available programmatically to assistive technology. Screen readers usually start by announcing the element’s name and role. For example, they say, “Submit, button.” Then, they announce its description, as in “Your information will be saved.”

To provide effective accessible names and descriptions, take the following steps:

Always use native HTML elements to name elements such as <label> for form controls, <legend> for grouped controls in a <fieldset>, and so on. HTML elements come with built-in behaviour that ARIA cannot replicate. They come with broad browser/AT support, and no risk of the author forgetting to keep two separate attributes in sync. For example:
1. Code for labels
```
<label for="email">Email address</label>
<input type="text" id="email" name="email" placeholder="Enter your email"/>
```
2. Code for Fieldsets and legends
```
<fieldset>
 <legend>Choose your favorite fruit</legend>.....
</fieldset>
```
Only use ARIA if native HTML is not feasible.
Let content-based roles such as buttons, links, and headings derive their name from their own visible text rather than adding an aria-label. They are designed to compute their name from what’s rendered inside them. Using aria-label doesn’t add information; instead, it replaces it, silently hiding the visible content from assistive technology users.
Code Example
```
<button aria-label="submit">Done</button>
```
In this example, a sighted user sees “Done,” but a screen reader user hears “Submit.” This creates a discrepancy and fails standard accessibility guidelines as well as creating two different experiences for two different users.
Reserve aria-label and aria-labelledby for cases where no appropriate visible text exists, such as icon-only controls. These labels can be helpful for assistive technology users, especially screen reader users, who rely on them.
Code Example
```
<button aria-label="Close">X</button>
```
Avoid using on attributes like title and placeholder as a primary naming strategy. These attributes are used for purposes such as adding tooltips and input hints and are adopted as accessible names as a last resort by browsers. For example:
1. Code for title
```
<button title="Close">X</button>
```
2. Code for placeholder
```
<input type="text" placeholder="Enter your name">
```
Compose names that are brief and genuinely useful, such as leading with the most distinguishing word, often a verb for action controls. While talking through the interface, screen reader users navigate to names by one, listening to each name readout individually. A name that is buried under words repeated multiple times on the page will impact every interaction with the page. For example:
1. “Edit John Doe,” “Delete John Doe,” “Message John Doe”, is the correct format to add an aria-label rather than “John Doe edit,” which requires the user to listen to the whole phrase to understand what the control does.
2. An “X” icon that closes a modal should be labeled “Close,” not “X” or “Close icon.”
Use aria-describedby or aria-description to associate instructions, formatting requirements, or extra context with an element, referencing visible or hidden text as needed. Descriptions should offer supplementary information which, if included in the name, would make it unnecessarily long or cumbersome. Keeping the name and description separate allows the primary announcement to remain concise, while allowing the descriptive information to be available to those who are interested.
Code Example
```
<label for="password">Password</label>
<input type="password" id="password" aria-describedby="password-help">
<p id="password-help">Your password must be at least 8 characters long.</p>
```
Reserve <title> for descriptions only as a last resort, since it is not reliably discoverable by sighted users without a mouse or by all AT.

The accessible name and description from the calculation algorithm may not always match what the user sees. Using only a single tool, such as the browser inspector, is not enough for verification. A check with at least one browser tool and one screen reader is necessary.

How to Test

Here is an overview of how you can check accessibility in code using browser tools and common screen readers.

Chrome/Edge: Open DevTools, then go to the Elements panel,select the node, and open the “Accessibility” pane in the right-hand sidebar. The pane displays the computed “Name,” “Role,” and “Description,” plus a “Computed Properties” section you can expand to find out which source (aria-labelledby, label, content, etc.) it came from.
NVDA: With NVDA, Tab or arrow keys, you can navigate through the page, and NVDA will announce the name/role/state of each item as you pass over it. Another very useful tool is “Speech Viewer” (in the tools menu), which displays a transcript of what NVDA is currently saying, making it easy to take down as evidence during an audit.
JAWS: Similar to the previous item, JAWS also has a virtual cursor “Elements List” (Insert + F7) that lists all the links, headings or form fields with an announced name (the name that will be spoken by the screen reader when navigating through the page). With this feature, you can quickly scan the entire page for possible missing or duplicated names.