ARIA Labels or Visible Text: Which Should You Use?

Screen reader users hear one thing. Sighted users see another. When those two diverge, your interface quietly breaks for the people who rely on assistive technology — and the fix is almost never "add more ARIA."

If you're deciding between an ARIA label and visible text on a button, link, or icon, here's the rule that resolves most cases: use visible text whenever it can do the job, and reserve ARIA for when it can't.

The core principle: accessible name comes from somewhere

Every interactive element needs an accessible name — the string a screen reader announces. Browsers compute it from several sources, roughly in this order of preference:

1. Visible text content inside the element (a <button>Save changes</button>)
2. Associated <label> for form fields
3. aria-labelledby pointing to another element's text
4. aria-label — a string that exists only for assistive tech
5. title attribute (last resort, inconsistently announced)

The first source — visible text — is the most robust. It can't drift out of sync with what's on screen, it works if CSS fails to load, and it's translatable by the same pipeline as the rest of your copy.

When visible text wins

Reach for visible text first in these situations:

• Buttons and links with room for a label. "Download report" beats an icon with aria-label="Download report".
• Form fields with a real label element. A <label for="email">Email address</label> is clickable, visible, and announced. Don't replace it with a placeholder plus ARIA.
• Navigation links. The link text is the label. "Pricing" is fine; you don't need to explain it.
• Anything a sighted keyboard user also needs to understand. If a control is visually ambiguous to a sighted user, ARIA won't fix that — it only patches the screen reader experience.

A useful test: turn off your CSS mentally. If the element still makes sense as plain text, you probably don't need ARIA.

When ARIA earns its place

ARIA is the right tool when the visible design genuinely can't carry the meaning. Common legitimate cases:

Icon-only buttons

A magnifying glass with no text needs a name: <button aria-label="Search">. There's no visible text to fall back on.

Repeated controls in a list

If a table row has a "Delete" button and a screen reader user hears "Delete, Delete, Delete," add context with aria-labelledby pointing at the row's title cell, or an aria-label like "Delete invoice 1042."

Visual context that isn't in the DOM

A "Read more" link following a headline can get aria-label="Read more about pricing changes" so it's meaningful out of context.

Decorative icons inside a labeled button

When a button already has text, the icon inside should be hidden from assistive tech with aria-hidden="true" so it isn't announced twice.

The trap: ARIA that contradicts visible text

This is where most accessibility audits find real damage. If a button visibly says "Buy now" but carries aria-label="Add to cart", you've created two different names for one control. Screen reader users and voice-control users may be working from a label that doesn't match what's on screen — and voice control software often relies on the visible text.

Two rules follow from this:

• Never let an aria-label override visible text with different wording. If the visible text is adequate, delete the ARIA.
• If you must extend a label, start with the visible text. aria-label="Buy now — adds item to cart" keeps the visible string intact and adds context.

aria-label vs aria-labelledby

Both set an accessible name, but they behave differently:

• aria-label takes a literal string. It's invisible by definition and won't be translated unless you route it through your i18n system.
• aria-labelledby references the id of an element already on the page. The name then updates automatically when that text changes — useful for tabs, dialogs, and repeated controls.

Prefer aria-labelledby when the text you want already exists in the DOM, because it can't fall out of sync. Use aria-label when there's no suitable visible text to point at.

A quick decision path

Work through these in order:

1. Is there visible text that already names the control? Use it. Stop.
2. Is there another element on the page whose text could serve as the name? Use aria-labelledby.
3. Is the control icon-only or ambiguous out of context? Use aria-label with the same words a sighted user would use.
4. Is the element purely decorative? aria-hidden="true".
5. Still unsure? Add visible text. It's the option with the fewest failure modes.

Testing it in practice

You don't need a screen reader to catch the worst cases, though testing with one is the only way to be sure.

• Keyboard-only pass. Tab through the page. Every focusable element should be reachable and its purpose clear from what's visible.
• Check the accessible name. Browser developer tools expose an accessibility panel showing the computed name for any element. If it differs from the visible text, investigate.
• Watch for duplicates. Listen for the same word announced twice — usually a decorative icon plus a text label, or a title attribute duplicating an aria-label.
• Zoom to 200%. If a label disappears at high zoom, your ARIA may be covering for a layout problem rather than a semantic one.

Accessibility issues like these rarely appear alone. They tend to cluster with missing focus styles, low-contrast text, and unlabeled form fields — all things a structured audit surfaces quickly. Run a free audit to see which accessibility and UX problems are actually present on your site before you start editing markup.

The short version

Visible text is the default. ARIA is the exception you reach for when the design leaves no visible alternative — icon-only controls, repeated actions, and context that lives outside the element. When you do use ARIA, keep it consistent with what's on screen, and prefer aria-labelledby over a hard-coded string when the text already exists. If you're weighing a fix and the visible-text option is viable, take it. It's the one that works for the widest range of users and the one least likely to break the next time someone edits the page.

For more step-by-step fixes across accessibility, speed, and SEO, browse the guides library.

More guides · Compare audit tools · Run a free website audit