A screen reader user lands on your site and moves through the header. What they hear is “button, button, link, link, button”. Every icon is announced by its type and nothing else. Or the opposite: a developer has added ARIA labels everywhere, and now the “Book a table” button is announced as “click”, and the social icons all say “link to page”.
Both problems come from the same place. ARIA is a set of attributes that changes what assistive technology announces, and an aria-label is the one people reach for first. Used in the right spot, it fixes a real barrier in one line. Used out of habit, it quietly makes things worse. This post is about when to use aria-label and when to leave it out.
What an aria-label actually changes
Every link, button and form control has an “accessible name”: the words a screen reader reads out, and the words voice control software listens for. Normally the browser works that name out from the content. A button containing the text “Subscribe” is named “Subscribe”. A link wrapping an image takes its name from the image’s alt text.
An aria-label attribute replaces that name. Whatever you put in it wins over the visible text inside the element. Three consequences follow:
- It is invisible. Sighted users never see it, so nobody notices when it is wrong.
- It overrides what is on screen. A button that shows “Get a quote” but has
aria-label="Submit"is announced as “Submit”. - It changes nothing else. It does not make a
divclickable, focusable or usable with a keyboard. It only changes the name.
WCAG covers this under 4.1.2 Name, Role, Value: controls need a name and a role that assistive technology can read. ARIA is one way to provide them, but usually not the best one.
The first rule: use HTML before ARIA
The W3C guidance on using ARIA starts with a simple rule: if a native HTML element already does the job, use it instead of adding ARIA to something else. A real <button> already has a role, keyboard support and a name from its text. A <div> with a role and a label added still needs keyboard handling written by hand, and that part is often forgotten.
The W3C’s authoring guide puts it more bluntly: no ARIA is better than bad ARIA. In practice, broken ARIA tends to cause more confusing screen reader output than missing ARIA, because a missing label is at least easy to spot.
When aria labels are the right tool
There are a few situations where an aria-label is the cleanest fix, and most sites have at least one of them.
Icon-only buttons
The magnifying glass that opens search. The hamburger that opens the mobile menu. The X that closes a popup. The heart that adds to a wishlist. None of these has visible text, so without help they are announced as just “button”. A short label fixes it:
<button type="button" aria-label="Open search">
<svg aria-hidden="true" focusable="false">...</svg>
</button>Note the aria-hidden on the icon itself, so the graphic is not announced twice. For more on which icons need words and which should be silent, see our post on decorative and informative icons.
Telling repeated regions apart
If a page has a main menu, a footer menu and a breadcrumb trail, a screen reader user listing regions hears “navigation, navigation, navigation”. Labels such as “Main”, “Footer” and “Breadcrumb” on each nav element make them distinguishable. Keep them short; the screen reader already says “navigation”.
Icon links with no text
Social icon links in a footer are the classic case. “Facebook” or “Our Facebook page” is a good name. “Link”, “icon” or the full URL is not.
When an aria-label does harm
These are the patterns that make a page harder to use.
Labels that contradict the visible text
Voice control users say what they see: “click Get a quote”. If the accessible name is “Submit form”, the command fails. Screen reader users who can partly see the screen get confused too. When a control has visible text, the accessible name should contain that text, ideally at the start. Usually the right move is to remove the label and let the visible text do the work.
Labels on things that cannot have them
An aria-label on a plain div, span or paragraph with no role is ignored by some screen readers and read by others. It is not a reliable way to add hidden explanations to content. If text matters, put it on the page.
Copies of the same vague label
A grid of blog cards where every “Read more” link has aria-label="Read more" adds nothing. A label of “Read more about holiday delivery dates” helps, though often the better fix is to make the visible link text descriptive.
aria-hidden on something people can focus
Hiding a focusable link or button with aria-hidden="true" creates a control that a keyboard user can land on but a screen reader announces as nothing, or as a blank. It is one of the most disorienting bugs there is.
Roles without behavior
Adding role="button" and a label to a div makes it sound like a button. If it does not respond to Enter and Space, it is a button that does not work. Our post on choosing between buttons and links explains why a real element is almost always simpler.
Common WordPress misuse
WordPress sites get most of their markup from themes, page builders and plugins, so ARIA problems usually arrive in bulk rather than one at a time.
- Theme menu toggles with stale labels. A hamburger labeled “Menu” is fine. One labeled “Open menu” that never changes after the menu opens is less fine, especially when the theme does not update
aria-expandedeither. - Page builder icon boxes. Some widgets let you set a link on an icon and fill in a label field. Leave the field empty and you may get an unnamed link; fill it with the icon’s name (“facebook-f”) and you get a meaningless one.
- Labels in the wrong language. A theme built elsewhere may hard-code labels such as “Buscar” or “Suche”. If your translation files do not cover them, a US visitor hears a word in another language.
- Labels added by an overlay script. Widgets that guess labels automatically sometimes add names to things that already had good ones. That is one reason we explain what overlays can and cannot fix before anyone installs one.
- Plugins that duplicate the theme’s work. Two plugins each adding a label to the same element, or a label added on top of good visible text, are both common after a few years of plugin installs.
How to check the names on your own pages
You can see what an element is called without a screen reader.
- In Chrome or Edge, right-click a button or icon and choose Inspect.
- In the developer tools panel, open the Accessibility tab. It shows the computed name and role for the element you selected.
- Compare that name with what is visible on screen. Does it match, or at least start with the visible words? Is it empty? Is it the word “button” or an icon class name?
- Check each icon-only control on each template: header, footer, mobile menu, product grid, popups.
Then listen. Even ten minutes of testing with NVDA through your header and a key page tells you more than reading attributes. Automated scanners catch missing names well, but only part of the bad ones: a label that says “click” passes most automated checks.
For a business that wants this done properly across a site, screen reader testing by a person is the step that finds wrong names rather than just missing ones. The rest of the picture, including how ARIA problems fit among the WCAG 2.2 AA criteria a business site is measured against, sits in our overview of website accessibility services.
Frequently asked questions
Should I add an aria-label to every link and button?
No. If a link or button already has clear visible text, that text is its name and an extra label usually just repeats or contradicts it. Add one when a control has no visible text, such as an icon button, or when several regions need telling apart. Everywhere else, better visible wording is the fix.
What is the difference between aria-label and alt text?
Alt text belongs on images and describes or names the image. An aria-label sets the name of an element such as a button or a navigation region. For a link that wraps an image, good alt text on the image is usually enough, and adding an aria-label on the link as well can override it.
Can ARIA make a div behave like a button?
Only in name. Adding a role and a label changes what a screen reader announces, not how the element works. It still needs to be focusable and respond to Enter and Space, which takes extra script. Using a real button element gives you all of that without any ARIA.
Do aria labels help with SEO?
Do not count on it. They are written for assistive technology, and there is no good evidence that search engines reward them. Descriptive visible text on links and buttons helps people and search engines alike, which is a better reason to write it than any hidden label.
Our WCAG audit checks the names, roles and states on your templates against 4.1.2 and the rest of Level AA, and lists each control that is unnamed or misnamed, with the fix. Often the best result is a page with fewer ARIA attributes than it started with.
Next in this series: Heading Structure for Accessibility: Get the Levels Right
