Add ARIA Labels

Add ARIA labels to buttons and links for better screen reader navigation.

Where and how to add ARIA for screen readers.

ARIA labels tell screen readers what your buttons and links actually do—because “Button 47” tells nobody anything.

A screen reader user just complained: “Your buttons make no sense. I hear ‘Button 47’ or ‘Link Link Link.'” They’re navigating by keyboard and audio. Your icon-only buttons with no text? Silent. Your generic “Click here” links? Useless out of context.

This isn’t a minor inconvenience. Over 7 million Americans use screen readers. When your checkout button announces “Button 47,” they leave. When your navigation makes no sense, they can’t use your site at all. That’s revenue lost and, increasingly, lawsuit risk—accessibility plaintiffs won 98% of cases in 2023.

ARIA labels help screen readers understand interactive elements, making your site accessible to blind users.

What Screen Readers Announce

When a screen reader hits a button, it says:

• The accessible name (what you control)
• The role (button, link, checkbox)

No accessible name? “Button 47” is the fallback when there’s nothing to read.

Three Fixes

1. Use Text Inside Buttons

Simplest. If the button has text, screen readers announce it:

Submit Form


 Download PDF

2. aria-label for Icon Buttons

Icon-only buttons need an accessible name:

3. Descriptive Link Text

“Click here” tells you nothing when read out of context:

Click here


View pricing plans

Screen reader users often navigate by links alone. “Click here, click here, click here” is useless.

Hidden Text (Visually Hidden)

Sometimes you want text for screen readers but not visible:

 
 Shopping cart, 3 items

The .sr-only class hides text visually but keeps it accessible:

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

Common ARIA Mistakes (And When Not to Use It)

The first rule of ARIA is: don’t use ARIA if native HTML can do the job. A <button> element already announces itself as a button. Adding role="button" to it is redundant. Adding role="button" to a <div> is worse—it announces “button” but doesn’t get keyboard focus, Enter/Space handling, or form submission behavior. You’ve created a lie.

Common mistakes that hurt more than they help:

• Overriding native semantics: Adding role="link" to an <a> tag, or aria-label to an element that already has clear visible text. The screen reader now ignores the visible text and reads only your label—confusing if they don’t match.
• Using aria-label on non-interactive elements: Screen readers may ignore aria-label on <div> or <span> elements without a role. The label goes nowhere.
• Placeholder as label: Using placeholder instead of <label> on form inputs. Placeholders disappear when you type—screen readers may not announce them at all.
• Duplicate landmarks: Two <nav> elements without distinguishing aria-label values. The screen reader says “navigation” twice with no way to tell them apart.

Diagnosis approach: Before adding any ARIA attribute, ask: can I fix this with native HTML instead? Use a <button> instead of a styled <div>. Use a <label> instead of aria-label. Use <nav aria-label="Main"> only when you have multiple nav regions. Native HTML is more robust, works without JavaScript, and doesn’t break when ARIA is implemented incorrectly.

Quick Audit

• Every icon-only button has aria-label?
• No “Click here” or “Read more” without context?
• Form inputs have associated labels?
• Images have alt text (or alt="" for decorative)?

Testing

• macOS: VoiceOver (Cmd + F5)
• Windows: NVDA (free) or JAWS
• Browser: Chrome DevTools – Accessibility panel

The standard: WCAG 2.1 Level A, 4.1.2 – All UI components must have an accessible name.

Confirming Screen Readers Announce Correctly

• All buttons and links have accessible names
• Form inputs have associated labels
• ARIA roles are used correctly (not overused)
• Screen reader announces elements as expected

Sources

• W3C – ARIA Authoring Practices Guide
• W3C – WCAG 2.1 Specification
• WebAIM – The WebAIM Million (Annual Accessibility Analysis)