WCAG 2.5.3: Label in Name

What This Rule Means

\n

WCAG 2.5.3 — Label in Name — applies to any user interface component that has a visible text label. The criterion requires that the accessible name of that component either matches the visible label text exactly or at minimum contains the visible label text as a substring. This prevents a situation where a user sees one label on screen but their assistive technology or speech recognition software recognises a completely different name behind the scenes.

\n

The accessible name is the name exposed to the accessibility tree and used by screen readers, voice control software, and other assistive technologies. It may come from a variety of sources including the element's visible text content, an aria-label attribute, an aria-labelledby reference, a title attribute, or an associated <label> element. When a developer overrides the accessible name with something that does not include the visible label text, a mismatch occurs and the criterion fails.

\n

Affected elements include any interactive component that displays text and also has an accessible name: buttons, links, form inputs with visible labels, menu items, tabs, checkboxes, radio buttons, and custom ARIA widgets. Non-interactive elements such as paragraphs or headings are not covered by this criterion.

\n

What counts as a pass: The accessible name contains the visible label text as a continuous substring, ignoring leading and trailing whitespace. The match is case-insensitive. For example, if a button reads "Search Products", an accessible name of "Search Products Now" passes because it contains "Search Products". An accessible name of "Find Products" fails because it does not contain the visible text.

\n

What counts as a fail: The accessible name is entirely different from the visible label, or the accessible name omits a meaningful portion of the visible label. A button that visually reads "Buy Now" but has aria-label='Purchase item' fails this criterion. Similarly, a link that reads "Contact Us" but is wrapped in an element with aria-label='Reach our team' also fails.

\n

Official exceptions defined in WCAG: The criterion does not apply to components where the label is purely symbolic or pictographic with no text equivalent (for example, an icon-only button with no visible text). It also does not apply when the text is part of a purely decorative element that carries no semantic meaning. Mathematical notation and language-specific scenarios where the text representation cannot map to a spoken word are also excluded. Additionally, components where the accessible name is intentionally expanded with additional context — provided the visible text is still present within the accessible name — are conformant.

\n\n

Why It Matters

\n

This criterion primarily protects users who rely on speech recognition software such as Dragon NaturallySpeaking (now Dragon Professional), Windows Speech Recognition, or Apple's Voice Control. These users navigate and activate interface elements by speaking the label they see on screen. When the accessible name does not match the visible label, the software cannot find the target element when the user speaks its name, effectively making the control unreachable without mouse or keyboard. For users with motor impairments — including those with repetitive strain injury, muscular dystrophy, cerebral palsy, or spinal cord injuries — voice input is often their primary or sole means of operating a computer. A mismatch on a single button can block access to an entire workflow.

\n

Screen reader users are also affected. When a screen reader announces an accessible name that differs from what is visible on screen, it creates cognitive disorientation. A sighted user who also uses a screen reader — for example, someone with low vision who uses both visual and auditory feedback simultaneously — may hear one thing announced while reading something different on screen, breaking their mental model of the interface.

\n

Users with cognitive disabilities benefit from consistency between what they read and what is spoken or announced. Unexpected name changes increase cognitive load and can cause confusion or errors, particularly for users with memory impairments or those who are learning to use a system for the first time.

\n

A concrete real-world scenario: Consider an e-commerce checkout page with a button that visually displays the text "Place Order". A developer adds aria-label='Submit purchase form' to provide what they consider a more descriptive name. A customer using Dragon NaturallySpeaking says "Click Place Order" — Dragon scans the accessibility tree, finds no element named "Place Order", and cannot activate the button. The customer cannot complete their purchase without switching to mouse control, which they may not be able to do. They abandon the transaction. This is not a hypothetical edge case; it is a common failure pattern found in automated audits across retail and banking websites.

\n

According to the World Health Organization, over one billion people worldwide live with some form of disability. The 2023 WebAIM Million report found that WCAG 2.5.3 label mismatches appeared in a meaningful proportion of audited pages, often introduced by well-intentioned but misapplied ARIA. Beyond accessibility, consistent labelling improves SEO because search engine crawlers that index link and button text for relevance ranking receive more meaningful signals when accessible names align with visible text.

\n\n

Related Axe-core Rules

\n

\n
• label-content-name-mismatch: This is the primary automated rule associated with WCAG 2.5.3. The rule checks interactive elements — such as buttons, links, and ARIA roles like role='button', role='link', role='menuitem', and role='tab' — that have both a visible text label and an accessible name. It flags any element where the accessible name does not contain the visible text as a substring (case-insensitive). The rule specifically targets elements where the accessible name is overridden by aria-label or aria-labelledby in a way that diverges from the on-screen text. Axe reports these as violations with impact level "serious" because they directly block speech input users from activating controls.
\n
• Limitations of automated detection: Automated tools like axe-core can reliably detect mismatches when the visible text is rendered as plain text nodes within the element and the accessible name comes from a static aria-label or aria-labelledby attribute. However, manual testing is required when: (1) the visible text is rendered through CSS ::before or ::after pseudo-elements, since these may or may not be included in the accessibility tree depending on browser and AT version; (2) the label is dynamically inserted via JavaScript after page load; (3) the visible text includes icons or image-based text where the textual component must be inferred; (4) the element's computed accessible name involves complex aria-labelledby chains that concatenate multiple elements. In these cases, a human tester using a screen reader must verify what is actually announced versus what is visible.
\n

\n\n

How to Test

\n

\n
1. Automated scan with axe DevTools or Lighthouse: Install the axe DevTools browser extension (Chrome or Firefox) or run a Lighthouse accessibility audit in Chrome DevTools. Trigger the scan on the fully rendered page — ensure that dynamic content, modals, and expanded menus are open if they contain interactive elements. In the axe results panel, filter by rule ID label-content-name-mismatch. Each flagged element will display its computed accessible name alongside the visible text, making the mismatch immediately apparent. Note the element selector and inspect the DOM to identify the source of the accessible name override. Lighthouse will surface the same failures under the "Accessibility" category with a reference to WCAG 2.5.3.
\n
2. Manual inspection with browser DevTools: Open the browser's Accessibility panel (Chrome DevTools → Elements → Accessibility tab, or Firefox DevTools → Accessibility tab). Select each interactive element that has visible text. Check the "Computed Properties" section for the element's Name field. Compare this value against the visible label. If the computed name does not contain the visible label text as a substring, the element fails 2.5.3.
\n
3. Screen reader testing with NVDA + Firefox: Open Firefox with NVDA running. Navigate to each interactive element using the Tab key. Listen to what NVDA announces as the element's name. Note any discrepancy between the announced name and the text displayed on screen. Use NVDA's Element List (Insert+F7) to browse all links and buttons and compare the announced names against visual labels in bulk.
\n
4. Screen reader testing with JAWS + Chrome: Open Chrome with JAWS running. Tab through all interactive controls. JAWS will announce the accessible name followed by the role. When the announced name does not include visible text, record the element. Additionally, use JAWS's "Browse Mode" and the virtual viewer to see the computed accessible name for each control.
\n
5. Screen reader testing with VoiceOver + Safari (macOS/iOS): Enable VoiceOver (Command+F5 on macOS). Use Tab or VO+Right Arrow to navigate interactive elements. VoiceOver announces the accessible name for each control. On iOS, swipe right with one finger to move through elements and listen for name-label discrepancies.
\n
6. Speech recognition test with Voice Control (macOS/iOS) or Dragon: Enable macOS Voice Control (System Settings → Accessibility → Voice Control). Say "Show names" to display labels for all interactive elements. Verify that the labels shown by Voice Control match the visible text on screen. Attempt to activate controls by speaking the visible label text — any control that does not respond to its visible name is a 2.5.3 failure. Repeat with Dragon NaturallySpeaking on Windows if available, using the "Click [label]" command.
\n

\n\n

How to Fix

\n\n

Button with overriding aria-label — Incorrect

\n

<!-- FAIL: aria-label completely replaces the visible text \"Search\"\n     with \"Execute query\", breaking speech input -->\n<button aria-label='Execute query'>\n  Search\n</button>

\n\n

Button with overriding aria-label — Correct

\n

<!-- PASS: Remove the mismatched aria-label entirely.\n     The button's visible text \"Search\" becomes its accessible name automatically.\n     Speech users can say \"Click Search\" to activate it. -->\n<button>\n  Search\n</button>\n\n<!-- PASS (alternative): If additional context is needed,\n     ensure the accessible name CONTAINS the visible text. -->\n<button aria-label='Search products'>\n  Search\n</button>

\n\n

Link with aria-labelledby pointing to unrelated text — Incorrect

\n

<!-- FAIL: aria-labelledby references a heading \"Our Services\"\n     but the link visually reads \"Learn more\",\n     so the accessible name is \"Our Services\" rather than \"Learn more\" -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' aria-labelledby='services-heading'>Learn more</a>\n</p>

\n\n

Link with aria-labelledby pointing to unrelated text — Correct

\n

<!-- PASS: Use aria-labelledby to concatenate the link's own text with the heading.\n     The accessible name becomes \"Learn more Our Services\",\n     which contains the visible label \"Learn more\". -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' id='learn-link' aria-labelledby='learn-link services-heading'>\n    Learn more\n  </a>\n</p>\n\n<!-- PASS (alternative): Make the visible link text self-descriptive\n     so no override is needed. -->\n<a href='/services'>Learn more about our services</a>

\n\n

Icon button where aria-label conflicts with visible text — Incorrect

\n

<!-- FAIL: The button shows a cart icon AND the text \"Cart\".\n     The aria-label 'View shopping basket' does not contain \"Cart\",\n     so speech users saying \"Click Cart\" get no response. -->\n<button aria-label='View shopping basket'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Icon button where aria-label conflicts with visible text — Correct

\n

<!-- PASS: The aria-label contains the visible text \"Cart\" as a substring.\n     Speech users can say \"Click Cart\" or \"Click View Cart\" and both work. -->\n<button aria-label='View Cart'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>\n\n<!-- PASS (preferred): Remove aria-label and hide the icon from the tree.\n     The button's text content \"Cart\" becomes the accessible name directly. -->\n<button>\n  <svg aria-hidden='true' focusable='false'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Form input with a visible label but mismatched aria-label — Incorrect

(Content truncated due to token limit — please retry this article.)