Short answer: aria-label gives an element a name for screen readers when there’s no visible text to use, such as a button with only an icon. If visible text exists, let it name the element, or point to it with aria-labelledby. When a control shows text, its name must contain that text.
What aria-label does
Every interactive element needs an accessible name, the name a screen reader announces. Most elements already have one: a button’s name is the text inside it, an image’s name is its alt text, and a form field’s name is its label. Our screen reader guide covers how to test your site with one.
aria-label gives an element a name written as text. MDN’s common example is a button with an SVG icon and no text. In practice, MDN notes, it’s supported only on interactive elements, widgets, landmarks, images and iframes. If the icon inside a named button is only decoration, our aria-hidden guide covers how to hide it from screen readers.
| Case | What to use | Why |
|---|---|---|
| Icon button with no text | aria-label | No visible text exists to reference |
| Visible text labels the element | The text itself, or aria-labelledby | Visible names are easier to keep up and to translate |
| Form field | A label element | Native HTML comes first |
| Image | The alt attribute | Alt text already names the image |
| Extra instructions | Visible text with aria-describedby | Instructions should reach every visitor |
Based on MDN and W3C, read November 4, 2026.
When aria-labelledby or visible text is better
W3C’s rules for naming prefer visible text. A name built from text on the screen is simpler to maintain, prevents bugs and needs less translation work. Its next rule is to prefer native HTML, such as the label element for form fields.
aria-labelledby points to text already on the page, so MDN recommends it over aria-label when a visible label exists. Don’t use both on one element: aria-labelledby takes precedence. An aria-label also overrides an image’s alt text or a field’s label.
Keep instructions out of names. MDN suggests visible text linked with aria-describedby, because aria-label content isn’t displayed outside assistive technologies. Our aria-describedby guide shows how to link that text.
The visible text must be part of the name
WCAG success criterion 2.5.3, Label in Name, at Level A, asks that a control showing text has a name containing that text. People who use voice control say the words they see, so “Send” on the screen must also be “Send” in the name.
W3C’s best practice is to put the visible text at the start of the name. Its naming rules also ask for brief, useful names: long or similar names make a page hard to use without a screen.
Our keyboard navigation guide covers moving through those controls without a mouse, and our alt text guide covers naming images.
How to check the names on your page
- Open the accessibility panel in your browser’s developer tools.
- Go through every button, link and form field and read the name it shows.
- Give each button that has only an icon an aria-label that says what it does.
- Where visible text exists, let it name the control, or point to it with aria-labelledby.
- Make sure each name contains the control’s visible text, ideally at the start.
- Keep names short and different from one another.
- Translate the labels with the rest of the page.
Our accessibility checker guide covers the automatic tests that also flag missing names.
How our own controls are named
On November 4, 2026 we read the accessibility tree of 10 of our pages in Chrome, at a desktop width and a phone width. Across the 20 views, all 2,096 links, buttons, switches and form fields had an accessible name.
198 of them were named with aria-label, such as the dark mode switch, the chat’s close button and the days in our booking calendar. Where a control also shows text, its name contains that text, as WCAG 2.5.3 asks.
Our Spanish pages carry their own labels, such as “Cambiar a modo oscuro” for “Switch to dark mode” and “Cerrar” for “Close”, written with the rest of each page.
Before you publish a page
- Every button, link and form field has a name.
- Buttons with only an icon have an aria-label.
- Visible text names its control where it exists.
- No element has both aria-label and aria-labelledby.
- Each name contains the visible text of its control.
- Labels are translated on every language version.
RememberUse visible text first and aria-label only when there’s none, and make every name contain the words people see.
Accessible, well named controls are part of our web design service.
Quick answers about aria-label
What is aria-label?
An attribute that gives an element an accessible name, the name screen readers announce. MDN’s common example is a button with only an SVG icon and no text, such as a close button.
What is the difference between aria-label and aria-labelledby?
Both give an element an accessible name. aria-label holds the text itself, while aria-labelledby points to visible text elsewhere on the page. If a visible label exists, MDN strongly recommends aria-labelledby.
Can I use aria-label and aria-labelledby together?
Don’t. MDN says aria-labelledby takes precedence when both are applied, so the aria-label text goes unused. Use aria-labelledby when visible text exists, and aria-label when it doesn’t.
Does aria-label replace alt text or a form label?
No. An image already takes its name from its alt text, and a form field from its label element. If you add aria-label anyway, MDN notes that it takes precedence over the alt text or the label.
What is label in name?
WCAG success criterion 2.5.3, at Level A. When a control shows text, its accessible name must contain that text, so people using voice control can say what they see. W3C’s best practice is to put that text at the start of the name.
Sources
Read on November 4, 2026. MDN Web Docs: ARIA: aria-label attribute and ARIA: aria-labelledby attribute. W3C Web Accessibility Initiative: Providing Accessible Names and Descriptions and Understanding SC 2.5.3 Label in Name (Level A). Our case: 10 of our pages read in Chrome on November 4, 2026.