2.5.3 Label in Name

WCAG 2.2 · 2.5.3 A Operable

What it requires

For any user-interface control that has a visible text label, the control’s accessible name must contain that visible label’s text. The match must be on the actual text presented to sighted users — ideally the visible text comes first in the accessible name, and word-for-word matching is best.

The point is that people who operate the page by voice say what they see. If a button reads “Search” on screen but its accessible name is “Submit query”, the command “click Search” fails. Keeping the visible label inside the accessible name keeps speech input, and any tool that maps spoken words to controls, working.

  • Speech-input users (Dragon, Voice Control, Voice Access) who activate a control by speaking its visible label — the primary group.
  • Screen-reader users who hear a name that contradicts the visible text, causing confusion when working alongside sighted colleagues.
  • Users with cognitive or memory disabilities who rely on the seen and spoken/announced words being the same.

How to detect it

Checks for 2.5.3 Label in Name
Check How What fails
Visible label vs. accessible name For each control with visible text, compare that text to its accessible name (inspect aria-label, aria-labelledby, alt text, or the associated <label>). Accessible name omits or rewords the visible text.
Screen reader Tab to the control and listen; the announced name should include the words you see. “Submit” announced where “Search” is shown.
Speech input Say “click visible label” and confirm the control activates. Command does nothing because the name differs.
Icon + text controls Check aria-label doesn’t replace the visible text with a synonym. aria-label="Close dialog" on a control labelled “Cancel”.
Automated tools Tools like axe flag some cases (e.g. when aria-label doesn’t contain the visible text). Partial — manual review is still required.

How to fix it

  1. Identify the visible label text exactly as users see it.
  2. Make sure that text is the control’s accessible name — for native controls, let the visible <label> or button text supply the name.
  3. If you must add aria-label, ensure it contains the visible text (best: starts with it, word-for-word).
  4. Don’t replace visible words with synonyms in aria-label or aria-labelledby.
  5. Re-test by speaking the visible label and with a screen reader.
<!-- Visible text is the accessible name -->
<button type="submit">Search</button>

<!-- aria-label still contains the visible label -->
<button type="submit" aria-label="Search flights">Search</button>

Copy-paste tests

Automated coverage

The axe-core rule label-content-name-mismatch flags failures of this criterion. Run it via the axe DevTools browser extension or axe-core in CI. Automated tools only catch some failures — manual review is still required.

Run this in the browser console

label-in-name-check.js 
// Surface controls whose accessible name may omit their visible text.
const norm = s => (s || '').replace(/\s+/g, ' ').trim().toLowerCase();
const suspects = [];
document.querySelectorAll('button, a[href], [role="button"], [role="link"]').forEach(el => {
  const visible = norm(el.textContent);
  const label = norm(el.getAttribute('aria-label'));
  if (visible && label && !label.includes(visible)) {
    suspects.push({ visible, accessibleName: label, node: el });
    el.style.outline = '2px solid red';
  }
});
console.table(suspects.map(({ node, ...r }) => r));
console.log(suspects.map(s => s.node));

What to check manually: say each control’s visible label with speech input (Voice Control / Dragon) and confirm it activates; verify names supplied via aria-labelledby, icons, or alt text — which this script can’t resolve — still contain the visible words.