ARIA label

At a glance

Why it matters

A control's accessible name is what a screen reader announces and what a speech-input user says to activate it. A button that holds only an icon has no name until one is supplied, so "Close", "Search" and "Delete" all come out as "button". aria-label fixes that. It also overrides any text the element already has, which is where it goes wrong: WCAG 2.5.3 fails a control whose visible label is missing from its accessible name, because a voice command that reads the screen no longer matches (W3C, Understanding 2.5.3).

ARIA is everywhere and still misused. WebAIM's 2026 scan found it on 82.7% of the top one million home pages, and pages that used it averaged 59.1 detectable errors against 42 on pages that did not (WebAIM Million, 2026). The W3C's first rule of ARIA use is to reach for a native HTML element or attribute with the semantics built in before adding ARIA at all (Using ARIA).

When should you use aria-label?

• Icon-only buttons and links. A close X, a search icon, a social link: aria-label="Close" gives the control a name a screen reader can say.
• Landmarks that need a name. WAI-ARIA 1.2 requires an accessible name on a dialog, a form and a region. When a visible heading exists, point at it with aria-labelledby instead.
• Repeated links that need context. Three "Read more" links can each name their article, as long as the visible words stay in the name: aria-label="Read more about pricing".
• Not on elements with visible text. The text is the name. Adding aria-label replaces it and risks a 2.5.3 failure.
• Not on a div or a span. Their generic role prohibits a name. Give the element the right role, or use the semantic element.
• Not as a tooltip. Sighted users never see aria-label.

Examples

Common mistakes

• Labeling an element that already has text. aria-label replaces the visible words. If they are not in the new name, the control fails WCAG 2.5.3 (failures F96 and F111).
• Putting it on a div or a span. The generic role prohibits a name, so assistive technology ignores the attribute and the element stays unnamed.
• Reaching for ARIA first. A <button> with text needs no ARIA. The first rule of ARIA is to use the native element.
• Naming the icon, not the action. "Magnifying glass" tells a screen reader user nothing; "Search" does.
• Using aria-label and aria-labelledby together. User agents give aria-labelledby precedence, so the aria-label is silently ignored.

Frequently asked questions

What is the difference between aria-label and aria-labelledby?

aria-label holds the name as a string you type. aria-labelledby points at the id of text already on the page and uses that text as the name. WAI-ARIA 1.2 says to use aria-labelledby when the label text is visible, and user agents give it precedence when both are present.

Does aria-label work on a div?

No. A plain div or span has the generic role, which prohibits an accessible name, so the attribute is ignored. Give the element a role, such as navigation or region, or use the semantic HTML element instead.

Should I add aria-label to a button that already has text?

No. The visible text is already the accessible name. If you must add context, keep the visible words inside the new name, or WCAG 2.5.3 Label in Name fails and speech-input users cannot activate the control by saying what they see.

Is aria-label read by screen readers?

Yes. A screen reader announces the accessible name, and aria-label sets it, so the value is read in place of the element's own content. It is never shown on screen.