Aria Label

Some things on a page have no visible text that could name them: a button with only an icon, a search field with a magnifying glass, a second navigation area, a chart drawn with SVG. Assistive technology still needs a name for each one. aria-label lets you write that name directly in an attribute.

It is the simplest ARIA attribute, and the one most often used wrongly. In this lesson you will learn exactly when it helps, and when you should reach for something better.

What You Will Learn

• What aria-label does, and what it overrides
• When to use it, and when not to
• Which elements it works on, and which it does not
• The Label in Name rule (WCAG 2.5.3)
• How to write short, unique, translatable labels
• How it compares with visible text, aria-labelledby, and title
• How to audit your labels

The Big Idea

HTML Code

index.html

<!-- An icon-only button -->
<button type="button" aria-label="Close">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

<!-- A search field with no visible label -->
<input type="search" aria-label="Search recipes">

<!-- Two navigation areas that need different names -->
<nav aria-label="Main">…</nav>
<nav aria-label="Footer links">…</nav>

<!-- An SVG picture with a name -->
<svg role="img" aria-label="Bar chart of weekly sales" viewBox="0 0 120 60">…</svg>

<!-- Visible text that already names the control: no aria-label needed -->
<button type="button">Save recipe</button>

Name Override Lab

http://127.0.0.1:5500/index.html

Pick an element
A button with visible textAn icon-only buttonA link that says Read moreA second navigation areaA search field with no visible labelA chart drawn with SVGA plain div

aria-label (leave empty to remove it)

What people see:

What a screen reader may say: Search recipes, button

• This works: a short name, with no repeated role, and any visible text is included.

Notice that aria-label replaces the name from the content: sighted people see "Search" while a screen reader hears your label. That is useful when there is no visible text, and risky when there is, because the two can drift apart. The spoken line is a simplified example, and different tools word it differently.

Try every example in the lab. Empty the label, and watch the icon button lose its name. Then change the "Search" button to say something different, and read the warning.

What aria-label Does

aria-label gives an element an accessible name as a plain text string. It is invisible: sighted people never see it. It is used by screen readers, voice control, and other assistive tools (see Accessible Names for the full picture).

Where it sits in the naming order matters:

1. aria-labelledby (if present) wins.
2. aria-label comes next.
3. After that: native labels, the element's own content, title, and placeholders.

This means aria-label replaces the name that would have come from the content. A button with the text "Search" and aria-label="Find recipes" is called "Find recipes" by a screen reader, even though everyone else sees "Search." That power is also the risk.

When to Use aria-label

Use it when there is no visible text to name the thing, and adding visible text would not make sense:

• Icon-only buttons and links: "Close," "Search," "Open menu."
• A search field whose purpose is clear from a nearby button or icon.
• Repeated landmarks: two nav elements, or two aside elements.
• Regions, groups, and toolbars with no visible heading: role="group", role="toolbar".
• SVG images and emoji groups with role="img".
• Custom widgets whose name has no visible source.
• Making a repeated link unique, when you cannot change the text ("Read more" becomes "Read more about rye bread"), as long as the visible text stays at the start of the label.

When Not to Use aria-label

Always ask first: is there visible text I can use instead? Visible text is better for everyone: it can be read, searched, translated, and zoomed.

Instead of this	Use this
aria-label on a field that needs a clear label	A visible label element
aria-label repeating the button's visible text	Nothing. Remove it.
aria-label when a visible heading names a section	aria-labelledby pointing at the heading
aria-label to describe a long hint	aria-describedby
aria-label on a plain div or span	A real element, a role, or visible text
aria-label on a p or text to "add a tooltip"	title is no better. Use visible text, or a proper tooltip pattern.
aria-label on an iframe	The title attribute

The next lesson, aria-labelledby, covers pointing a name at text that is already on the page.

Elements That Can and Cannot Be Named

aria-label should only be used on elements that have a role that accepts a name.

Works well	Not reliable
button, a, input, select, textarea	A plain div or span (no role)
Landmarks: nav, aside, main, section, form	p, strong, em, and other text elements
Elements with a role: role="img", role="group", role="dialog", role="tablist", role="tab"	code, b, i, u, small
table, figure, fieldset	Elements with role="presentation" or role="none"

In the current ARIA rules, a name is prohibited on roles such as generic (a plain div or span), paragraph, presentation, strong, emphasis, code, and a few more. Some screen readers still read them, others ignore them, and the results change between versions, so do not depend on it. If you want a div to have a name, give it a proper role, or restructure the HTML.

Label in Name: Match What People See

WCAG success criterion 2.5.3 (Label in Name) says: if a control has visible text, the accessible name must contain that text, ideally at the start.

Why? Voice control users say what they see. If the screen shows "Search," they say "click Search." If your hidden name is "Find recipes," that command fails. People who use a screen reader together with sighted colleagues, or who read the screen and listen at the same time, hear something that does not match what is shown.

<!-- Bad: the visible word is not in the name -->
<button type="button" aria-label="Find recipes">Search</button>

<!-- Good: the visible text comes first -->
<button type="button" aria-label="Search recipes">Search</button>

<!-- Good: a unique name for a repeated link -->
<a href="/rye" aria-label="Read more about rye bread">Read more</a>

Writing a Good Label

1. Name the action or the purpose, not the picture: "Close," not "X" or "Cross icon."
2. Keep it short. Two to four words is usually plenty. Put long help in a description.
3. Do not repeat the role. "Close," not "Close button." "Main," not "Main navigation."
4. Make it unique among things of the same kind. Two buttons that both say "Delete" need to say what they delete: "Delete rye bread recipe."
5. Do not put the state in the label. If a toggle is "Favourite," use aria-pressed for on and off, instead of changing the label to "Unfavourite."
6. Include the visible text, and start with it.
7. Write it in the page language, in normal case, with no tricks like all capitals or symbols.
8. Avoid abbreviations and jargon that a voice reading aloud may mispronounce.

Practice Writing Labels

Try writing labels for five situations. You get instant feedback, and you can reveal a sample answer.

http://127.0.0.1:5500/index.html

Pick a situation
Situation 1Situation 2Situation 3Situation 4Situation 5

The situation: A dialog has a corner button that shows only an X. It closes the dialog.

Your aria-label

A screen reader may say: (no name), button

Feedback: Needs work.

• Write a label. With no text and no aria-label, the control has no name.

These are simple rules of thumb. Other good answers exist, and the best label depends on the page around it.

aria-label or Something Else?

Method	Good for	Watch out for
Visible text (content or label)	Almost everything	Needs room in the design
Visually hidden text (a screen-reader-only class)	Icon buttons, where you want the text to translate and be found like normal content	Needs a CSS class, and extra markup
aria-label	Short names for things with no visible text	Invisible, ignored on plain div and span, may be skipped by some translation tools
aria-labelledby	Naming something from text already on the page	The id must exist
title	A tooltip for mouse users, as a last-resort name	Not reliably announced, not shown to keyboard or touch users

Visible text, or visually hidden text, is often the safest choice for multilingual sites, because translation tools reliably translate it. See the global notes below.

Audit Your Labels

The audit below reads every element with an aria-label in a snippet of HTML, and flags empty labels, labels on plain div or span, role words in labels, labels that do not contain the visible text, labels that only repeat the visible text, labels that override a visible form label, and duplicates.

http://127.0.0.1:5500/index.html

On a real site, you can also:

1. Search your code for aria-label, and for each one ask: could visible text do this?
2. Open the Accessibility panel in your browser's DevTools, and read each name.
3. Use a screen reader on your icon buttons and landmarks. Do they make sense in a list of links, buttons, and landmarks?
4. Test voice control: say "click" and the visible text of each control.
5. Run a checker (axe, Lighthouse) for missing names and mismatches.

Good Habits

1. Use visible text first, and aria-label only when there is none.
2. Keep labels short, unique, and action-focused.
3. Start the label with the visible text when there is any.
4. Never repeat the role in the label.
5. Use aria-label only on elements that can have a name.
6. Hide decorative icons with aria-hidden="true" when you name the button.
7. Include labels in your translation process.
8. Check names in the Accessibility panel, and with voice control.

Accessibility Checklist

• Every control with no visible text has a name (aria-label or hidden text).
• No aria-label repeats visible text, or contradicts it.
• Visible text is included at the start of the accessible name (WCAG 2.5.3).
• Repeated landmarks have different names, and no role words.
• aria-label is not used on plain div or span elements, or on text elements.
• Labels are short, in the page language, and unique where needed.
• Labels do not carry state (use aria-pressed and similar).
• Decorative icons inside named controls are hidden.
• Labels are part of the translation process.
• Names were checked in the Accessibility panel and with real assistive technology.

Security and Privacy Notes

• aria-label is public. Anyone can read it in the page source, and assistive technology reads it aloud. Do not put personal data, account numbers, tokens, or internal notes in it.
• Do not use it to mislead. A label that says "Cancel" on a button that confirms a payment, or a hidden name that differs from the visible text in a harmful way, deceives people who cannot see the screen. It is also a form of clickjacking-style trickery.
• Be careful with names that include user data. "Delete message from Sam" in a shared workspace may be read aloud to people nearby. Weigh it up for sensitive content.
• Escape user-generated text before it goes into an attribute, to prevent script injection. Never place raw input inside aria-label.
• Do not use labels to detect assistive technology (for example, by checking whether a hidden label is read). That could reveal a disability.
• Hidden text is not secret. Do not use aria-label to hide content from sighted users that you would not want them to know about.

Global Audience Notes

• Translate aria-label with the rest of your page. It is content, not code. Make sure your translation workflow includes attributes. Some automatic page-translation tools may not translate them, so test with the tools your readers use, or prefer visible or visually hidden text where translation matters.
• Keep labels short. Translated words are often longer, and short, plain words translate better (and are easier for people reading in a second language).
• Set the page language with lang, so the screen reader voice speaks your labels correctly. If a label contains a name or word from another language, wrap that in visible text with its own lang instead.
• Voice control users speak in their own language. Another reason to include the visible text in the name.
• Avoid symbols and slang in labels, such as "X," "hamburger," or "thumbs up." They may be read oddly, or not translate.
• Right-to-left languages: write the label in the direction of its language, and test mixed text with numbers or Latin words, which can appear in an unexpected order.
• Do not repeat state words such as "expanded" in the label. Screen readers say them in the user's own language.

Common Mistakes to Avoid

1. Icon-only buttons with no name at all.
2. aria-label that does not contain the visible text.
3. aria-label repeating the visible text.
4. Role words in the label ("Close button," "Navigation").
5. aria-label on a plain div or span with no role.
6. The same label on several elements ("Navigation," "Navigation").
7. An empty aria-label="".
8. Overriding a visible label with a different hidden one.
9. Long, sentence-style labels.
10. Changing the label to show state ("Mute," then "Unmute," with aria-pressed).
11. Forgetting to translate labels.
12. Never checking names in the Accessibility panel.

Practice Time

Try these in your browser and your editor:

1. Use the name override lab for each element, and write down the name a screen reader would hear.
2. Give the "Search" button a label that does not contain "Search," and read the warning. Then fix it.
3. In the writing practice, write your own label for each situation before you look at the sample.
4. Run the audit on the messy HTML, fix every problem, and run it again.
5. Find three icon-only buttons in a project, and give each a good label.
6. Give two nav elements different names, and check them in the Accessibility panel.
7. Replace one aria-label with visually hidden text, and compare how it behaves with a page-translation tool.
8. Use aria-label to make three "Read more" links unique, keeping "Read more" at the start.
9. Turn on voice control (if you have it), and say "click" and a visible label.
10. Bonus: search a site you like for icon buttons, and open DevTools to see which have good names.

Quick Recap

Click a question to check your answer.

1. What does aria-label do?

It gives an element an invisible, text accessible name, which replaces the name that would come from its content.

2. When should you use it?

When there is no visible text to name a control, such as an icon-only button, a search field, a repeated landmark, or an SVG image.

3. Why is aria-label on a plain div a problem?

A plain div has no role that accepts a name, so the label is not reliably announced. Use a real element, give it a role, or use visible text.

4. What does "Label in Name" require?

The accessible name must contain the visible text of the control, ideally at the start, so voice control users can say what they see.

5. Why not write "Close button" as a label?

Screen readers already say "button," so it would be read twice. Write "Close."

6. What is often safer than aria-label on a multilingual site?

Visible text, or visually hidden text, because translation tools reliably translate it, and some may not translate attributes.

Key Takeaways

• aria-label is an invisible name, written as text. It replaces the name from the content.
• Use it only when there is no visible text, and prefer visible text, a label, or aria-labelledby when you can.
• It works on named roles, such as buttons, links, inputs, landmarks, and role="img". It is not reliable on plain div and span.
• Include the visible text in the name (WCAG 2.5.3).
• Keep labels short, unique, and free of role words and state.
• Translate labels, and consider hidden text for multilingual sites.
• Check names in the Accessibility panel, and with voice control and a screen reader.

Next, learn how to name something from text that is already on the page with aria-labelledby.