What is aria-label?
In the world of web accessibility, the aria-label attribute plays a crucial role. It gives an element an accessible name, the text a screen reader announces to identify it, when the element has no visible text that can do the job. Screen readers, voice control software and other assistive technologies rely on that name to tell users what a control is for.
Essentially, aria-label is an attribute you add to an HTML element. Its value is read by assistive technology but is not displayed on the page. It is defined in the W3C’s WAI-ARIA 1.2 specification, and MDN’s aria-label reference lists where it is supported. Used well, it makes icon-only controls understandable. Used carelessly, it hides useful text or creates names that do not match what sighted users see.
Why Use aria-label?
There are a few situations where aria-label is the right tool:
- Icon-only buttons and links: When a button or link shows only an icon,
aria-labelsupplies the text a screen reader needs. - Distinguishing repeated elements: When a page has two navigation regions or several identical “Remove” buttons, a label can tell them apart.
- Controls with no visible text to reference: For custom widgets where there is no on-screen text you could point to with
aria-labelledby.
Practical Examples of aria-label
Let’s look at real-world examples of how aria-label can be used effectively.
Example 1: Icon Button
Imagine a social media site with a heart icon for the “like” action. Without any text, screen reader users only hear “button”. Here’s how aria-label helps:
<button type="button" aria-label="Like this post"><img src="heart.png" alt=""></button>
The aria-label="Like this post" attribute names the button, and the empty alt stops the screen reader from also reading the image file. (An equally good option is to drop aria-label and put alt="Like this post" on the image; either gives the button a name. Our alt text guide explains when images need text.)
Example 2: Search Button
A search form often submits with a magnifying glass icon. Without a name, it is not apparent that the icon means “search”.
<button type="submit" aria-label="Search"><img src="search.png" alt=""></button>
Here, aria-label="Search" tells assistive technology users that the button submits a search.
Example 3: Close Button
Many dialogs have an “X” icon to close them. A label makes the purpose clear:
<button type="button" aria-label="Close dialog"><img src="close.png" alt=""></button>
Without it, a screen reader might announce “button”, or read out a stray “X” character, which tells the user nothing.
Example 4: Two Navigation Landmarks
If a page has both a main menu and a footer menu, screen reader users moving between landmarks hear “navigation” twice. A label tells them which is which:
<nav aria-label="Main">...</nav> <nav aria-label="Footer">...</nav>
Keep landmark labels short and leave out the word “navigation”; the screen reader already announces the role, so aria-label="Main navigation" would be read as “Main navigation navigation”.
Example 5: Forms: Use a Real Label First
Form fields are where aria-label is most often misused. A visible <label> helps everyone: sighted users can see what to enter, clicking the label focuses the field, and the screen reader gets the same name.
<!-- Prefer: visible label --> <label for="email">Email address</label> <input id="email" type="email" autocomplete="email"> <!-- Acceptable only when the purpose is visually obvious, e.g. a lone search field next to a Search button --> <input type="search" aria-label="Search the site">
A placeholder is not a label. It disappears as soon as someone starts typing, and it is often low contrast.
Example 6: Telling Repeated Buttons Apart
A shopping cart with a “Remove” button on every row sounds like “Remove, button; Remove, button” to a screen reader user. You can keep the visible word and add context:
<button type="button" aria-label="Remove Blue T-shirt">Remove</button>
Note that the label starts with the visible word “Remove”. That matters for voice control users, as the next section explains.
When NOT to Use aria-label
The W3C’s first rule of ARIA, from Using ARIA, is to use native HTML before ARIA. The APG’s Read Me First page sums it up: no ARIA is better than bad ARIA. For aria-label that means:
- Do not replace visible text. If a button already says “Save”, adding
aria-label="Submit form"overrides it, so screen reader users hear something different from what everyone else sees. - Do not use it on plain text containers. On a generic
div,spanorpwith no role, many screen readers ignorearia-labelentirely. It is meant for interactive elements, landmarks and widgets. - Do not use it instead of alt on informative images. Use the
altattribute for that. - Do not stuff it with instructions. A name should be short (“Search”), not a sentence (“Click here to search our entire website”). Put extra help in visible text or
aria-describedby. - Watch out for translation. Browser translation tools do not always translate attribute values, so an
aria-labelcan stay in English on a page that has been translated. Visible text, oraria-labelledbypointing at visible text, avoids that.
aria-label vs aria-labelledby: A Quick Decision Tree
- Can you use a native label? A
<label>for form fields, text inside a<button>or<a>, oralton an image. If yes, do that and stop. - Is there visible text elsewhere on the page that names the element? For example, a heading above a section or a dialog title. If yes, use
aria-labelledbyto point to it. See our aria-labelledby guide. - Is there no visible text at all? Use
aria-label.
This order follows how browsers calculate accessible names. Under the accessible name computation, aria-labelledby wins over aria-label, and aria-label wins over native sources such as a <label>, element content or alt. So if you add aria-label to an element that already has a visible name, yours replaces it. The APG’s guide to providing accessible names and descriptions covers this in detail.
aria-label and WCAG 2.5.3 Label in Name
WCAG success criterion 2.5.3 Label in Name (Level A) says that when a control has a visible text label, its accessible name must contain that text, ideally at the start. Voice control users say what they see (“click Remove”), and if the accessible name is “Delete item” the command fails. W3C’s Understanding 2.5.3 explains the requirement, and technique G208 shows the fix: include the visible text, in the same order, at the start of the name. That is why Example 6 uses “Remove Blue T-shirt”, not “Delete Blue T-shirt from cart”.
A missing or wrong name usually also fails WCAG 4.1.2 Name, Role, Value, which requires every control to expose a name to assistive technology.
How the Browser Picks the Name: A Worked Example
It helps to see the precedence in action. Take this button:
<h2 id="cart-title">Your cart</h2> <button type="button" aria-labelledby="cart-title" aria-label="Basket"> <img src="cart.png" alt="Shopping cart"> View </button>
The button has three possible names: the text it points to with aria-labelledby (“Your cart”), its aria-label (“Basket”), and its content (the image alt plus the word “View”). The browser uses the first one that exists, in that order, so the accessible name is “Your cart”. The visible word “View” is ignored, which also breaks Label in Name. The fix is to keep one naming method: remove both attributes and let the content give the name “Shopping cart View”, or better, change the content to plain visible text such as “View cart”.
You can check the result without a screen reader. In Chrome, Edge or Firefox, open developer tools, select the element and look at the Accessibility panel; it shows the computed name and where it came from.
Frequently Asked Questions
Does aria-label work on every element?
No. It is reliable on interactive elements (links, buttons, form fields), landmarks such as nav and section with a name, and elements with a widget role. The WAI-ARIA specification prohibits naming some roles, including generic (a plain div or span), paragraph and presentation, so screen readers may ignore it there.
Is aria-label bad for SEO?
Search engines index visible content, so a label that only lives in an attribute adds nothing for them. That is one more reason to prefer visible text where you can; aria-label is there for users of assistive technology, not for keywords.
Should I use aria-label or a visually hidden text span?
Both give an accessible name. Visually hidden text (a CSS class that hides text from sight but not from screen readers) is more likely to be translated by browser tools and is easy to keep in sync with the HTML. aria-label is simpler for one-word icon buttons. Pick one per component and be consistent.
Do I need aria-label on links that open in a new tab?
Not to say “opens in new tab” on its own. If you want to warn users, add the warning to the link text or a visually hidden span, so it adds to the visible name rather than replacing it.
Best Practices for aria-label
- Be concise: One to three words is usually enough for a control.
- Match the visible label: If there is visible text, start the label with it.
- Do not repeat the role: “Close”, not “Close button”.
- Prefer visible text: If the text can be shown on screen, show it and skip
aria-label. - Test: Check the accessible name in your browser’s accessibility panel, then listen to it with a screen reader. Our guides to screen reader testing and automated accessibility testing show how; automated tools reliably catch missing names but cannot tell you whether a name makes sense.
Conclusion
aria-label is a powerful tool when an element has no visible text to name it: icon buttons, duplicate landmarks and the occasional custom widget. Use native labels first, point to visible text with aria-labelledby where it exists, keep labels short and make sure they contain the visible text. Test with real assistive technology, and you will give every user a clear, consistent experience.
To keep learning, read our ARIA essentials quick-start guide, our overview of ARIA attributes and our guide to aria-expanded.
Related Resources
Work With Us
Not sure if your labels are actually working for screen reader users? Our accessibility audit tests this with real assistive technology, not just automated scanners.
Get a free accessibility needs assessment — no commitment required.
