Accessible names for interactive controls

Every button, link, and form field has an accessible name — the short text that assistive technology announces when the control receives focus. When that name is missing, vague, or out of sync with the visible label, people who navigate by screen reader or by voice can’t tell what a control does. Voice-control users in particular say a button’s visible words to click it, so a mismatched name leaves the control unreachable. Getting the accessible name right is one of the highest-leverage accessibility fixes you can make.

What you’ll learn

How to give an icon-only button a name, why “click here” link text fails users who navigate by links, and how to keep a control’s visible label and its accessible name in agreement so voice control still works.

Standards this lesson maps to
Standard Criterion Level What it requires
WCAG 2.2 4.1.2 Name, Role, Value A Every interactive control exposes a name and role to assistive technology.
WCAG 2.2 2.4.4 Link Purpose (In Context) A The purpose of each link can be determined from its text or context.
WCAG 2.2 2.4.9 Link Purpose (Link Only) AAA The purpose of each link is clear from the link text alone.
WCAG 2.2 2.5.3 Label in Name A The accessible name contains the visible label text.
EN 301 549 9.4.1.2 (incorporates WCAG 4.1.2) — European harmonised standard; references the WCAG A/AA set.
Section 508 502.3 / 503.4 (incorporates WCAG A & AA) — US federal ICT must meet WCAG 2.0 Level A and AA, including name/role/value.
ADA Title II WCAG 2.1 AA (DOJ rule) AA US state/local government web content must conform to WCAG 2.1 AA.
EAA EN 301 549 → WCAG A & AA AA European Accessibility Act relies on EN 301 549, which references WCAG.

The three problems we’ll fix

The cards below each isolate one common naming defect. For every issue you get a plain-language statement of the problem, a Bad example (shown as escaped, non-running code so it can’t harm this page), a Good example, the copyable Code, and an ordered fix.

Icon-only button with no name

WCAG 2.2 · 4.1.2 A EN 301 549 Section 508

A button whose only content is an icon or an SVG has no text for assistive technology to announce. A screen reader reads it as just “button”, and a voice-control user has no word to speak to activate it. The control is visible but effectively nameless.

Bad

The button holds only an SVG. Nothing names it, so it is announced as a bare “button”.

bad-icon-button.html 
<button type="button">
  <svg viewBox="0 0 24 24" aria-hidden="true">
    <path d="M3 6h18M3 12h18M3 18h18"/>
  </svg>
</button>

Good

Give the button a visually hidden text label, or an aria-label. The icon stays decorative with aria-hidden. This live button is named “Open menu”.

good-icon-button.html 
<button type="button">
  <svg viewBox="0 0 24 24" aria-hidden="true" focusable="false">
    <path d="M3 6h18M3 12h18M3 18h18"/>
  </svg>
  <span class="visually-hidden">Open menu</span>
</button>

Code

The same pattern using aria-label when you can’t add a child element — for example on an <a> acting as a button.

aria-label-button.html 
<button type="button" aria-label="Open menu">
  <svg viewBox="0 0 24 24" aria-hidden="true" focusable="false">
    <path d="M3 6h18M3 12h18M3 18h18"/>
  </svg>
</button>

How to fix

  1. Add a real text label inside the button in a visually-hidden span, or set aria-label on the button.
  2. Mark the icon as decorative with aria-hidden="true" and focusable="false" so it isn’t announced or focused.
  3. Make the name match what a sighted user would call the control, so voice-control commands work.
  4. Verify with a screen reader or the browser’s accessibility tree that the button is announced as “Open menu, button”.

Link text that says only “click here”

WCAG 2.2 · 2.4.4 A 2.4.9 AAA EN 301 549

Screen reader users often pull up a list of every link on the page to navigate. A list full of “click here”, “read more”, and “learn more” is useless out of context — none of the entries say where they go. Link text should describe its destination on its own.

Bad

Out of context this link reads as “click here” and nothing more.

bad-click-here.html 
<p>
  To download the report,
  <a href="/report.pdf">click here</a>.
</p>

Good

The link text itself names the destination, so it makes sense in a links list. This live link is named “Download the 2026 accessibility report (PDF)”.

Download the 2026 accessibility report (PDF)

good-link-text.html 
<p>
  <a href="/report.pdf">
    Download the 2026 accessibility report (PDF)
  </a>
</p>

Code

If the design demands short visible text, extend the name with a visually-hidden span so the full purpose still reaches assistive technology.

visually-hidden-link.html 
<a href="/report.pdf">
  Read more
  <span class="visually-hidden">
    about the 2026 accessibility report
  </span>
</a>

How to fix

  1. Rewrite the link so its visible text describes the destination on its own — name the page, document, or action.
  2. Avoid generic phrases like “click here”, “read more”, and “learn more” as the whole link.
  3. When visible text must stay short, append context in a visually-hidden span inside the link.
  4. If a file type or size matters, include it in the text, e.g. “(PDF)”.

Visible label doesn’t match the accessible name

WCAG 2.2 · 2.5.3 A EN 301 549 ADA Title II

When a control’s visible text is “Search” but its aria-label is “Submit query”, voice-control users who say “click Search” get nothing — the spoken words aren’t in the accessible name. Label in Name requires the accessible name to contain the visible label text, ideally at the start.

Bad

The visible word is “Search” but aria-label overrides the name to “Submit query”, which no longer contains “Search”.

bad-label-in-name.html 
<button type="submit" aria-label="Submit query">
  Search
</button>

Good

Drop the conflicting aria-label and let the visible text be the name, so “Search” is both seen and spoken. This live button is named “Search”.

good-label-in-name.html 
<button type="submit">Search</button>

Code

If you need a longer name, keep the visible text at the start of it so the spoken label still matches.

extended-name.html 
<!-- Visible word "Search" leads the accessible name -->
<button type="submit" aria-label="Search the catalogue">
  Search
</button>

How to fix

  1. Prefer the visible text as the accessible name — usually that means removing the conflicting aria-label.
  2. If you must extend the name, start it with the exact visible label text so the match holds.
  3. Don’t let placeholder text or an icon title silently replace the visible label.
  4. Test by speaking the visible words with voice control to confirm the control activates.

Recap

  • Every interactive control needs an accessible name (WCAG 4.1.2).
  • Name icon-only buttons with a visually-hidden span or aria-label, and hide the icon from assistive technology.
  • Write link text that describes its destination on its own (2.4.4 / 2.4.9).
  • Keep the visible label inside the accessible name so voice control works (2.5.3 Label in Name).

Same defect, same standards across WCAG, EN 301 549, Section 508, ADA Title II, and the EAA — fix the name once and you satisfy them all.