ARIA labels are HTML attributes that give an element its accessible name, the name a screen reader announces, when the visible content cannot do that job, and the most used one, aria-label, sets the name from a text string that never appears on screen. Its partner aria-labelledby takes the name from text already on the page, and aria-describedby adds extra detail that is read after the name.
Used well, these attributes fix icon buttons, unnamed regions and vague dialogs. Used badly, they hide the real text from screen reader users and break voice control. Here is when to reach for each one and when to leave them out.
Quick facts
aria-label
Name from a text string; not shown on screenaria-labelledby
Name taken from visible text, referenced by idaria-describedby
Extra description, read after the name and roleFirst rule of ARIA
If a native HTML element or attribute does the job, use that insteadWorks best on
Links, buttons, form fields, landmarks, dialogs and widgets with a roleWCAG links
4.1.2 Name, role, value; 2.5.3 Label in name; 1.3.1 Info and relationships
What are ARIA labels?
ARIA stands for Accessible Rich Internet Applications, a W3C specification that adds roles, states and properties to HTML for assistive technology. Three of its attributes deal with names and descriptions.
| Attribute | What it does | Shown on screen? | Typical use |
|---|---|---|---|
aria-label | Sets the accessible name from a string | No | Icon-only buttons, a second nav landmark |
aria-labelledby | Sets the name from other elements, by id | Yes, the referenced text is visible | Dialogs named by their heading, grouped controls |
aria-describedby | Adds a description after the name | Usually yes | Password rules, error messages, hints |
When a browser works out the name, aria-labelledby wins over aria-label, which wins over the element's own content or its label element. The title attribute comes last. That order is why a stray aria-label can silently replace good visible text.
The first rule of ARIA: use HTML first
The first rule of ARIA says that if a native HTML element or attribute already gives the meaning and behaviour you need, use it instead of adding ARIA. Native elements come with keyboard support, roles and names for free, and they work in more browser and screen reader combinations.
Better than any ARIA: a real label tied to the field.
<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email">Other native naming tools: the text inside a button or link, alt on an image, legend inside a fieldset, and caption on a table.
ARIA labels in HTML: icon buttons and landmarks
aria-label earns its place where there are no words on screen. The classic case is a button that shows only an icon.
Fails: the only thing announced is the word "button".
<button class="close">
<svg viewBox="0 0 16 16">...</svg>
</button>Passes: screen readers now say "Close, button".
<button class="close" aria-label="Close">
<svg aria-hidden="true" focusable="false" viewBox="0 0 16 16">...</svg>
</button>It also tells two landmarks of the same type apart, so screen reader users moving by region know which one they are in:
<nav aria-label="Main">...</nav>
<nav aria-label="Breadcrumb">...</nav>aria-labelledby: reuse text already on screen
When the right name is already visible, point to it. This keeps what sighted users read and what screen reader users hear in step, and translators only have to change one string.
<div role="dialog" aria-modal="true" aria-labelledby="dlg-title">
<h2 id="dlg-title">Delete this file?</h2>
...
</div>You can list several ids separated by spaces, and the browser joins their text in that order. It even works when the referenced element is hidden, which is handy but easy to misuse.
aria-describedby: hints and error messages
A description is extra information that is read after the name and role, often after a short pause. It suits instructions and error messages, which should not become part of the name.
<label for="pw">Password</label>
<input id="pw" type="password" aria-describedby="pw-rules">
<p id="pw-rules">At least 12 characters, with one number.</p>Screen readers announce this as "Password, edit, protected" followed by the rules. Some let users turn descriptions off, so never put essential information only there.
Common mistakes with ARIA labels
| Mistake | What users get | Fix |
|---|---|---|
| aria-label on a plain div or span | Ignored or read unreliably, because those elements have no role | Use a real element, or give it a suitable role |
| aria-label that differs from the button text | Voice control users say the visible word and nothing happens | Remove it, or start it with the visible words |
| Labelling decorative graphics | Extra noise on every page | Hide them with aria-hidden="true" |
| Ten links all called "Read more" | A list of identical links | Make the visible text specific, or extend the name |
| Copying the role into the label | "Search button, button" | Name only: "Search" |
| Long sentences in aria-label | Slow, tiring announcements | Keep names to a few words; use a description for the rest |
An aria-label on a link or button replaces its visible text completely for screen readers. If the words differ, the element breaks the label in name rule (2.5.3).
How to check ARIA labels with a screen reader
Start in the browser. Chrome, Edge, Firefox and Safari all have an accessibility panel in their developer tools that shows the computed name, role and description of the selected element.
Then listen. On Windows, start NVDA with Ctrl+Alt+N, switch to Firefox or Chrome, and press Tab to reach each control. On a Mac, turn on VoiceOver with Command+F5 and use Safari. Microsoft's built-in Narrator and the paid JAWS are worth a pass on important flows. Guides: NVDA, VoiceOver, and our full screen reader testing method.
ARIA and WCAG
People searching for ARIA WCAG rules often expect a list of required attributes. There is none: WCAG does not require ARIA. ARIA is one technique for meeting several criteria when native HTML falls short:
- 4.1.2 wants every custom control to report its name, role and current state.
- 2.5.3 wants that name to include the label people see.
- 1.3.1 wants visual relationships, like a field and its hint, to exist in code.
- 4.1.3 wants updates announced through live regions.
Reference: the MDN aria-label page and the W3C ARIA Authoring Practices Guide, which shows tested patterns for tabs, menus, dialogs and more.
Questions people ask
What does aria-label mean?
aria-label is an attribute that gives an element an accessible name from a text string. Screen readers announce that name, but it does not appear on screen.
When should I use aria-label instead of a visible label?
Only when there are no visible words to use, such as an icon-only button or a second navigation landmark. If visible text exists, use it directly or point to it with aria-labelledby.
What is the difference between aria-label and aria-labelledby?
aria-label holds the name as a string you type into the attribute. aria-labelledby points to other elements by id and uses their text, so the name stays in sync with what is on screen. If both are present, aria-labelledby wins.
Does aria-label work on a div?
Not reliably. A div or span with no role has nothing for a name to attach to, so many screen readers ignore it. Use a real element such as a button, or add an appropriate role.
Do all screen readers read aria-label?
On links, buttons, form fields and landmarks, current versions of NVDA, JAWS, VoiceOver, TalkBack and Narrator read it. Support is weaker on static text and generic elements, which is another reason to prefer visible text.
Do ARIA labels help with SEO?
Do not count on it. ARIA exists for assistive technology, and visible text is what matters for search. Write ARIA labels for screen reader and voice control users.