ARIA Labels Explained: How to Fix Unlabeled Buttons, Links, and Icons for Screen Reader Users

If your website has buttons with no text, icon links, or image-only navigation, screen reader users are hitting dead ends every time they interact with your site. They hear "button," "link," or "image" — nothing more. No context, no purpose, no usability. This is one of the most common WCAG failures we see, and it's also one of the most fixable. Understanding how to use aria-label for buttons and icons correctly can close this accessibility gap in under an hour for most sites.

Why Unlabeled Interactive Elements Are a Legal and UX Problem

Accessibility lawsuits in the United States have exceeded 4,000 filings per year, with e-commerce and small business websites increasingly in the crosshairs. The majority of ADA Title III web cases involve WCAG 2.1 Level AA failures — and missing accessible names on interactive elements consistently rank among the top violations cited.

Under WCAG 2.1 Success Criterion 4.1.2, every user interface component must have a name that can be programmatically determined. That means screen readers like NVDA, JAWS, and VoiceOver need to be able to announce what a button or link does. If your "X" close button, hamburger menu, or shopping cart icon has no accessible name, you're in violation — and potentially liable.

Beyond legal risk, there's a business cost. Approximately 26% of U.S. adults live with some form of disability. Inaccessible interfaces drive these users away before they convert.

What Is an ARIA Label and When Should You Use It?

ARIA stands for Accessible Rich Internet Applications. It's a set of HTML attributes that bridge the gap between what something looks like visually and what assistive technology can communicate to a user.

The aria-label attribute lets you attach a descriptive text string directly to an element — one that screen readers announce but sighted users don't see on screen.

Use aria-label when:
- A button contains only an icon (SVG, font icon, or image)
- A link's visible text doesn't clearly describe its destination
- An interactive element has no visible text at all

Don't use aria-label when:
- The element already has visible text — use that text or supplement it with aria-describedby
- You can simply add visually hidden text with CSS instead (often a cleaner solution)

The Most Common Unlabeled Element Failures (With Fixes)

Icon-Only Buttons

This is the number one offender on most small business websites. Social share buttons, close modals, play/pause controls — they often look like this:

<!-- BROKEN: Screen reader announces "button" with no context -->
<button>
  <svg>...</svg>
</button>

Fix it with aria-label:

<!-- FIXED: Screen reader announces "Close menu, button" -->
<button aria-label="Close menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Note the aria-hidden="true" on the SVG. This prevents the screen reader from attempting to read the SVG's internal elements and doubling up on announcements. Always pair this with aria-label on the parent button.

Icon Links

Navigation icons — like a shopping cart linking to checkout or a phone icon linking to a contact page — suffer the same issue:

<!-- BROKEN -->
<a href="/cart">
  <img src="cart-icon.png">
</a>

<!-- FIXED -->
<a href="/cart" aria-label="View shopping cart">
  <img src="cart-icon.png" alt="">
</a>

Here, the image alt is intentionally empty because the link's accessible name is handled by aria-label. If you use both a non-empty alt and aria-label, some screen readers will announce both — creating a redundant, confusing experience.

Hamburger Menu Toggles

<!-- BROKEN -->
<button class="hamburger" onclick="toggleNav()">
  <span></span><span></span><span></span>
</button>

<!-- FIXED with dynamic state -->
<button 
  class="hamburger" 
  aria-label="Open navigation menu" 
  aria-expanded="false"
  onclick="toggleNav(this)">
  <span aria-hidden="true"></span>
  <span aria-hidden="true"></span>
  <span aria-hidden="true"></span>
</button>

Use JavaScript to toggle both aria-label and aria-expanded when the menu opens and closes. Screen reader users need to know both what the button does and what state the menu is currently in.

The Visually Hidden Text Alternative

Some developers prefer using visually hidden CSS text instead of aria-label. Both approaches are valid. This method is especially useful when the label might need to be translated or updated by a CMS:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

<button>
  <svg aria-hidden="true" focusable="false">...</svg>
  <span class="sr-only">Open search</span>
</button>

This is particularly recommended for internationalized sites where aria-label values would need to be hardcoded in multiple languages.

How to Audit Your Site for Missing Labels

You don't need to manually review every element. Here's a fast audit process:

1. Run WAVE or axe DevTools — Both free browser extensions will flag elements with missing accessible names immediately. Look for "Empty button," "Linked image missing alternative text," and "Missing form label" errors.
2. Test with a screen reader — Tab through your navigation and interactive elements using VoiceOver (Mac/iOS) or NVDA (Windows). If you hear "button" or "link" without context, you've found a violation.
3. Check your icon library implementation — Font Awesome, Material Icons, and similar libraries often render icons as <i> or <span> tags. These need aria-hidden="true" plus a labeled parent, or they inject meaningless character codes into the accessibility tree.

Quick Reference: When to Use Each Approach

Don't Overcorrect: Common aria-label Mistakes

Using aria-label for buttons and icons incorrectly creates new problems:

• Don't duplicate visible text. If a button already says "Submit," adding aria-label="Submit" is redundant but harmless. Adding aria-label="Submit your form" overrides the visible label, which can confuse users who rely on both visual and auditory cues.
• Don't use aria-label on non-interactive elements like <div> or <p> unless they have an appropriate ARIA role.
• Don't forget focus management. An accessible name is only part of the equation. Buttons and links also need visible focus indicators (WCAG 2.4.7).

Fix It Once, Fix It Right

Implementing proper aria-label for buttons and icons across your site is not a complex project — but it does require a systematic audit to find every unlabeled element. Missing even one high-traffic button (like a checkout CTA or a mobile menu toggle) leaves a segment of your users unable to complete core actions.

The sites that get hit with accessibility complaints aren't always the ones with the worst code. They're often the ones with one or two overlooked elements that created a broken experience for the wrong user at the wrong time.

Ready to find every missing label on your site? Scan your site for free at wcagrepair.com and get a remediation guide with exact code fixes for $8.99 — specific to your site, prioritized by severity, and written so your developer can implement it without guesswork.