Free scan

October 20, 2026

aria-label: when to use it and when to avoid it

When should you use aria-label? When an element has no accessible name, or an inaccurate one, and no visible content in the DOM can be referenced to name it. aria-label is primarily for assistive technologies such as screen readers. The textbook case is a button that contains nothing but an SVG icon. If visible text already labels the element, reference that text instead; and on some structural roles, aria-label is simply not supported. This guide walks through what the attribute does, when it helps, when it hurts, and how the first rule of ARIA applies, with code examples (including one from MDN), drawing on MDN's documentation and, for the first rule of ARIA, on the W3C document "Using ARIA".

What aria-label does

According to MDN, aria-label defines a string value that can be used to name an element, as long as the element's role does not prohibit naming. The value is plain text, and it becomes the accessible name of the object.

Most content already gets an accessible name without ARIA. By default, a button's accessible name is the content between its opening and closing <button> tags, an image's is the content of its alt attribute, and a form input's is the content of its associated <label> element. aria-label should only come in when none of these options is available, or when the default name is not appropriate.

Keep in mind that aria-label content is not displayed outside assistive technologies. MDN therefore advises making important information visible to everyone.

When to use aria-label: icon buttons and landmarks

The classic case is an icon-only button. With no text, it has no accessible name, so a screen reader user cannot tell what it does. In MDN's example below, the button contains only an SVG icon, and aria-label="Close" states its function. The SVG carries aria-hidden="true" and focusable="false".

MDN notes that while aria-label can in principle be used on any element that can have an accessible name, in practice it is supported only on interactive elements, widgets, landmarks, images and iframes. It is intended for elements including links, videos, form controls, and those with landmark or widget roles, when no visible label exists in the DOM.

For landmarks, aria-label lets you name an element with a landmark role when no visible label exists in the DOM. If visible text that labels it does exist, reference it with aria-labelledby instead, as explained below.

<!-- Icon button (MDN example, path shortened) -->
<button aria-label="Close">
  <svg aria-hidden="true" focusable="false" width="17" height="17"
       xmlns="http://www.w3.org/2000/svg">
    <path d="…" fill="black" />
  </svg>
</button>

When not to use aria-label

Case one: the element already has visible text that labels it. MDN is explicit: if there is visible text that labels an element, use aria-labelledby. aria-label is meant for cases where the text that could label the element is not visible.

Case two: HTML already provides the name. If you have given an <iframe> a title, an <img> an alt attribute or an <input> a <label>, aria-label is not necessary. And if it is present anyway, it takes precedence over the iframe's title, the image's alt or the label text as the accessible name. A superfluous aria-label therefore takes precedence over the native label.

Case three: certain structural roles that cannot be named. Neither aria-label nor aria-labelledby should be used with inline structural roles such as code, term and emphasis, or with roles not mapped to the accessibility API, including none. MDN lists the roles where aria-label is not supported:

<!-- Avoid: the label already exists, aria-label overrides it -->
<label for="email-1">Email address</label>
<input id="email-1" type="email" aria-label="Field">

<!-- Correct: the <label> is enough -->
<label for="email-2">Email address</label>
<input id="email-2" type="email">

aria-label or aria-labelledby?

Both attributes provide an accessible name. The difference is where the text comes from: aria-labelledby points to text already in the DOM, while aria-label holds the text itself. MDN strongly recommends prioritizing aria-labelledby when a visible label exists and can be referenced for an acceptable user experience. If there is no visible name to reference, use aria-label.

Never use both on the same element: aria-labelledby takes precedence over aria-label when both are applied.

Finally, aria-label is not for instructions. To add guidance or clarify the UI, MDN recommends visible text with aria-describedby or aria-description. Instructions should be accessible to all users, not just screen reader users, and a more intuitive UI is better still.

The first rule of ARIA: native HTML first

The W3C document "Using ARIA" states the first rule of ARIA use: if you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Brought to aria-label, this principle suggests looking for the native solution first. MDN points the same way: with a title on an <iframe>, an alt on an <img> or a <label> for an <input>, aria-label is not necessary. aria-label is for when no native name is available, or the default name is not appropriate, and no visible text can be referenced, as with the icon button above.

The W3C lists three exceptions to the first rule: the feature is available in HTML but not implemented, visual design constraints rule out the native element, or the feature is not currently available in HTML. The other rules say not to change native semantics unless you really have to, to make all interactive ARIA controls usable with the keyboard, and not to put role="presentation" or aria-hidden="true" on a focusable element.

Note that "Using ARIA" is now published as a Discontinued Draft (no longer intended to advance or to be maintained). The W3C points to the ARIA Authoring Practices Guide (APG) for further guidance on using ARIA in design patterns and widgets.

Auditing your aria-label attributes

When reviewing a site, go through every element carrying aria-label and ask these questions, drawn from the guidance above.

Frequently asked questions

When should I use aria-label?

Use it when an element has no accessible name, or an inaccurate one, and no visible text in the DOM can name it, such as an icon-only button. Its value becomes the element's accessible name.

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

Both provide an accessible name. aria-labelledby references text already in the DOM; aria-label contains the text directly. Prefer aria-labelledby when a visible label exists, and don't use both together: aria-labelledby wins.

Can aria-label be used on any HTML element?

No, it depends on the element's role: aria-label is intended for elements whose role does not prohibit naming. MDN says it is not supported on roles such as generic, paragraph, strong, code or mark. In practice, however, it is supported only on interactive elements, widgets, landmarks, images and iframes.

Does aria-label override an image's alt attribute?

If both are present, aria-label takes precedence over alt as the accessible name. But if the image already has an alt, aria-label is not necessary: keep the native attribute.

What is the first rule of ARIA?

According to the W3C, if a native HTML element or attribute already has the semantics and behavior you need, use it instead of re-purposing an element and adding an ARIA role, state or property.

Further reading on Conformly

Sources

This article relies on the official sources listed at the end of the page.