The 2025 TestParty Guide to WCAG 2.5.3 – Label in Name (Level A)

Why did the voice control user get frustrated with the "Submit" button? Because its accessible name was "Send Form Now" and saying "Click Submit" did absolutely nothing. Talk about a name-calling problem!

WCAG 2.5.3 Label in Name requires that when a button, link, or input field displays visible text, that exact text must be included in its accessible name. This ensures voice control users can activate controls by speaking what they see on screen.

Table of Contents

• What WCAG 2.5.3 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 2.5.3
• How TestParty Helps
• FAQs

What WCAG 2.5.3 Requires

When a user interface component shows a text label, the accessible name (what assistive technology reads) must contain that visible text. The match doesn't need to be exact, but the visible label text must appear somewhere in the accessible name.

Key requirements:

• The visible label text must be present in the accessible name
• The match is case-insensitive and ignores punctuation
• Best practice: start the accessible name with the visible label text
• Applies to buttons, links, form inputs, and any interactive component with a visible text label

What's covered:

• Buttons with text labels
• Links with visible text
• Form inputs with visible labels
• Custom controls with text labels
• Icons accompanied by visible text

Exceptions:

• Icons without visible text labels (covered by other criteria)
• Components where the visible label is purely symbolic
• Text that's part of a logo or brand name used as a control

Why This Matters

Voice control users navigate by speaking what they see. When someone using Dragon NaturallySpeaking or Voice Control says "Click Submit," the software searches for controls with "Submit" in their accessible name. If your button shows "Submit" but has an accessible name of "Send Form," the command fails.

This creates a frustrating disconnect between what users see and what they can say. Users are forced to guess alternative phrasings or use less efficient navigation methods like "show numbers" mode.

Legal and compliance context:

WCAG 2.5.3 is a Level A requirement, making it mandatory for ADA compliance, Section 508 conformance, and EN 301 549 adherence. The European Accessibility Act also requires Level A conformance for most digital products and services starting in 2025.

Organizations face legal risk when voice control users cannot operate their websites. Several ADA lawsuits have cited failures where visible labels didn't match accessible names, preventing speech input users from completing transactions or accessing services.

Business benefits:

Beyond compliance, matching labels to names improves the experience for millions of voice control users—including people with motor disabilities, repetitive strain injuries, and those who prefer hands-free interaction. Better voice control support means better conversion rates and customer satisfaction.

Quick Implementation Guide

1. Use the visible label text as the accessible name

For most controls, the visible text automatically becomes the accessible name. Don't override it unnecessarily.

<!-- Good: Visible text matches accessible name -->
<button>Submit Application</button>
<a href="/contact">Contact Us</a>
<label for="email">Email Address</label>
<input type="text" id="email">

2. When adding context, include the visible label

If you need to provide additional context via aria-label or aria-labelledby, make sure the visible text appears in the accessible name—preferably at the start.

<!-- Good: Visible label "Search" is at the start -->
<button aria-label="Search products and articles">
  Search
</button>

<!-- Bad: Visible label "Search" is missing -->
<button aria-label="Find products and articles">
  Search
</button>

3. For icon + text combinations, include the text

When a control contains both an icon and visible text, the text must be in the accessible name.

<!-- Good: Visible "Download" text is included -->
<button>
  <svg aria-hidden="true"><!-- download icon --></svg>
  Download
</button>

<!-- Bad: Only describes the icon -->
<button aria-label="Download icon">
  <svg><!-- download icon --></svg>
  Download
</button>

4. Match label text for form inputs

The <label> element's text should match any aria-label or aria-labelledby content.

<!-- Good: Label text matches -->
<label for="phone">Phone Number</label>
<input type="tel" id="phone">

<!-- Bad: Label says "Phone Number" but aria-label differs -->
<label for="phone">Phone Number</label>
<input type="tel" id="phone" aria-label="Telephone">

5. Start with the visible label

When the accessible name includes additional context, put the visible label text first. This makes voice commands more reliable.

Key techniques: G208 (including visible label text in accessible name), G211 (matching accessible name to visible label)

Common Mistakes to Avoid

Replacing visible text with different ARIA labels

The most common failure is using aria-label to provide a "more descriptive" name that completely replaces the visible text. Voice users can't activate these controls by speaking what they see.

<!-- Bad: Visible "Buy Now" doesn't appear in accessible name -->
<button aria-label="Purchase this product">Buy Now</button>

<!-- Good: Visible text is included -->
<button aria-label="Buy Now - Add to cart">Buy Now</button>

Abbreviated visible labels with full accessible names

When the visible label is abbreviated but the accessible name is spelled out (or vice versa), voice commands fail.

<!-- Bad: Visible "FAQ" but accessible name is "Frequently Asked Questions" -->
<a href="/faq" aria-label="Frequently Asked Questions">FAQ</a>

<!-- Good: Visible text is in the accessible name -->
<a href="/faq" aria-label="FAQ - Frequently Asked Questions">FAQ</a>

Icon-only accessible names when text is visible

When a control shows both an icon and text, hiding the text from the accessible name breaks voice control.

Mismatched form labels

Using different text in the <label> element versus aria-label or placeholder text creates confusion and voice control failures.

How to Test for WCAG 2.5.3

Automated checks:

• Scan for controls with aria-label or aria-labelledby that don't contain their visible text
• Flag buttons and links where inner text doesn't match accessible name
• Identify form inputs where label text differs from ARIA attributes

Manual verification:

• Visually inspect each interactive control with a text label
• Use browser DevTools to check the accessible name (Accessibility tree in Chrome/Firefox)
• Verify the visible label text appears in the accessible name
• Test with voice control software (Dragon, Voice Control, Voice Access) to confirm commands work

Testing checklist:

• [ ] All buttons with visible text include that text in their accessible name
• [ ] All links with visible text include that text in their accessible name
• [ ] Form input labels match any ARIA labeling attributes
• [ ] Icon + text controls include the visible text in accessible names
• [ ] Voice commands using visible label text successfully activate controls

How TestParty Helps

TestParty's automated scanning and AI-powered remediation specifically targets Label in Name violations across your entire codebase, catching mismatches before they reach production.

What TestParty detects:

TestParty analyzes the DOM and source code to identify controls where the visible text doesn't appear in the accessible name. The platform:

• Extracts visible text content from buttons, links, and form controls
• Computes the accessible name using the full accessibility tree calculation (including aria-label, aria-labelledby, title, and native labeling)
• Flags mismatches where visible text is missing from the accessible name
• Detects cases where visible text appears in the accessible name but not at the start (suboptimal for voice control)
• Identifies form inputs where <label> text differs from aria-label or aria-labelledby content
• Catches icon-only accessible names when visible text is present

The scanner works across vanilla HTML, React, Vue, Angular, and other frameworks, parsing both server-rendered and client-side rendered components.

How TestParty suggests fixes:

For each Label in Name violation, TestParty generates specific remediation guidance:

• Simple mismatches: Auto-suggests removing or modifying aria-label attributes to include the visible text
• Context additions: Recommends patterns like aria-label="[Visible Text] - [Additional Context]" that preserve the visible label at the start
• Form label conflicts: Suggests aligning <label> text with ARIA attributes or removing redundant ARIA
• Icon + text controls: Proposes accessible name structures that include both icon semantics and visible text

All AI-generated fixes are reviewed by your team or TestParty accessibility specialists before committing. The platform provides inline explanations of why each change is necessary and how it improves voice control support.

Developer workflow integration:

TestParty integrates directly into your development process to prevent Label in Name violations from shipping:

• CI/CD gates: Block pull requests that introduce controls with mismatched labels and accessible names
• IDE integration: Surface Label in Name issues in VS Code, IntelliJ, and other editors with line-level annotations and one-click fix suggestions
• Pull request reviews: Automated comments on PRs flag new violations with specific code locations and remediation steps
• Pre-commit hooks: Catch issues before code is even committed to version control

This shift-left approach is especially valuable for Label in Name compliance because these violations often result from well-intentioned attempts to make controls "more descriptive"—catching them early prevents the pattern from spreading.

Ongoing monitoring:

After remediation, TestParty continuously monitors for regressions:

• Automated regression testing: Scans on every deploy to catch new Label in Name violations
• Component library tracking: Monitors shared components and design system elements for label/name mismatches that would cascade across pages
• Trend dashboards: Visualize Label in Name compliance over time, broken down by component type, page template, or team
• Audit-ready reports: Generate documentation showing Label in Name conformance for legal, procurement, or certification requirements

For ecommerce platforms and sites with thousands of pages built from templates, TestParty's theme-level analysis ensures fixes to shared components automatically improve Label in Name compliance across your entire site.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.

FAQs About WCAG 2.5.3

What is WCAG 2.5.3 Label in Name in plain language?

WCAG 2.5.3 requires that when a button, link, or form control shows visible text, that exact text must be included in the name that assistive technology reads. This ensures voice control users can activate controls by speaking what they see on screen, rather than guessing alternative phrasings.

Is WCAG 2.5.3 required for ADA compliance?

Yes. WCAG 2.5.3 is a Level A success criterion, which means it's part of the baseline accessibility requirements. ADA compliance typically requires meeting WCAG 2.1 Level AA, which includes all Level A criteria like 2.5.3. Organizations that fail to meet this requirement face legal risk, especially when voice control users cannot complete transactions or access services.

Does the accessible name need to match the visible label exactly?

No, the accessible name doesn't need to be an exact match—it just needs to contain the visible label text. You can add additional context before or after the visible text. However, best practice is to start the accessible name with the visible label text to make voice commands more reliable.

What's the difference between a label and an accessible name?

A label is the visible text users see on screen (like "Submit" on a button). An accessible name is what assistive technology reports to users—it might come from the visible text, an aria-label attribute, an aria-labelledby reference, or other sources. WCAG 2.5.3 requires that the visible label text appears in the accessible name.

Can I use aria-label to make my buttons more descriptive?

Yes, but you must include the visible label text in the aria-label. For example, if your button shows "Search," you can use aria-label="Search products and articles" because it contains "Search." Don't use aria-label="Find items" because the visible text "Search" is missing, which breaks voice control.

How does WCAG 2.5.3 relate to other WCAG criteria?

WCAG 2.5.3 works alongside other labeling requirements. WCAG 1.3.1 (Info and Relationships) requires controls to have programmatic labels. WCAG 4.1.2 (Name, Role, Value) requires controls to have accessible names. WCAG 2.5.3 adds the specific requirement that the accessible name must contain the visible label text, ensuring voice control compatibility.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is WCAG 2.5.3 Label in Name in plain language?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "WCAG 2.5.3 requires that when a button, link, or form control shows visible text, that exact text must be included in the name that assistive technology reads. This ensures voice control users can activate controls by speaking what they see on screen, rather than guessing alternative phrasings."
      }
    },
    {
      "@type": "Question",
      "name": "Is WCAG 2.5.3 required for ADA compliance?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. WCAG 2.5.3 is a Level A success criterion, which means it's part of the baseline accessibility requirements. ADA compliance typically requires meeting WCAG 2.1 Level AA, which includes all Level A criteria like 2.5.3. Organizations that fail to meet this requirement face legal risk, especially when voice control users cannot complete transactions or access services."
      }
    },
    {
      "@type": "Question",
      "name": "Does the accessible name need to match the visible label exactly?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No, the accessible name doesn't need to be an exact match—it just needs to contain the visible label text. You can add additional context before or after the visible text. However, best practice is to start the accessible name with the visible label text to make voice commands more reliable."
      }
    },
    {
      "@type": "Question",
      "name": "What's the difference between a label and an accessible name?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A label is the visible text users see on screen (like 'Submit' on a button). An accessible name is what assistive technology reports to users—it might come from the visible text, an aria-label attribute, an aria-labelledby reference, or other sources. WCAG 2.5.3 requires that the visible label text appears in the accessible name."
      }
    },
    {
      "@type": "Question",
      "name": "Can I use aria-label to make my buttons more descriptive?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes, but you must include the visible label text in the aria-label. For example, if your button shows 'Search,' you can use aria-label='Search products and articles' because it contains 'Search.' Don't use aria-label='Find items' because the visible text 'Search' is missing, which breaks voice control."
      }
    },
    {
      "@type": "Question",
      "name": "How does WCAG 2.5.3 relate to other WCAG criteria?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "WCAG 2.5.3 works alongside other labeling requirements. WCAG 1.3.1 (Info and Relationships) requires controls to have programmatic labels. WCAG 4.1.2 (Name, Role, Value) requires controls to have accessible names. WCAG 2.5.3 adds the specific requirement that the accessible name must contain the visible label text, ensuring voice control compatibility."
      }
    }
  ]
}