When the Label Lies: WCAG Failure F96 and Speech Input Users

No visible label. No match. No access.

WCAG Failure F96 (opens in new window) describes a specific pattern where the accessible name of a control diverges from what's printed on screen — and the people who pay the price are speech input users. This is one of those failures that gets introduced with good intentions. A developer wants to add context for screen reader users. They reach for aria-label or aria-labelledby. The result looks fine visually. It passes automated scans. And it completely breaks the experience for someone using Dragon NaturallySpeaking or Windows Speech Recognition to navigate the web.

The Failure

F96 documents violations of WCAG 2.5.3 Label in Name (opens in new window), a Success Criterion introduced in WCAG 2.1 that requires the accessible name of a user interface component to contain the visible label text. The word "contain" matters here — the accessible name can be longer than the visible label, but the visible string must appear within it, intact.

The W3C document surfaces three distinct failure patterns:

Pattern 1 — Direct override. A button reads "Go" on screen. The developer adds aria-label="Find in this site" to provide more context. The accessible name is now "Find in this site" — the word "Go" appears nowhere in it.

<!-- FAILS: accessible name contains no part of visible label "Go" -->
<button id="sitesearch" aria-label="Find in this site">Go</button>

Pattern 2 — Hidden text interruption. A link reads "Download specification" visually. Hidden text is injected mid-phrase to produce the accessible name "Download gizmo specification." The visible label text is technically present — but not as a contiguous string.

<!-- FAILS: "Download specification" is not a contiguous string in the accessible name -->
<a href="#">Download <span class="accessibly-hidden">gizmo</span> specification</a>

Pattern 3 — aria-labelledby override of input value. A submit input has value="search" (the visible label). An aria-labelledby reference points to hidden text reading "Find in this site." Because aria-labelledby takes precedence in the accessible name computation algorithm (opens in new window), the accessible name becomes the hidden text — and "search" is gone.

<!-- FAILS: aria-labelledby overrides value; accessible name no longer contains "search" -->
<span id="hidden-label" class="accessibly-hidden">Find in this site</span>
<input type="submit" aria-labelledby="hidden-label" value="search">

All three patterns share the same root cause: the accessible name computation produces a string that doesn't include the text a user can actually read.

Why This Matters

Speech input users navigate by speaking what they see. That's the fundamental interaction model. When someone says "click Go" or "click Download specification," their software looks for a control whose accessible name matches that spoken string. If the accessible name is "Find in this site" instead of "Go," the command fails. The button is right there on screen — visible, seemingly clickable — and the user can't activate it by voice.

This isn't a minor friction point. For people who rely on speech input as their primary input method — including many people with motor disabilities, repetitive strain injuries, or conditions affecting fine motor control — this failure can make a form completely unusable. They can see the button. They can read the label. They just can't say the right magic words because the developer changed them invisibly.

The failure is particularly insidious because it often originates from an accessibility improvement gone wrong. Someone added aria-label to provide better context for screen reader users. That's a reasonable instinct. But WCAG 2.5.3 (opens in new window) requires that both populations be served simultaneously — the accessible name must contain the visible text, not replace it.

This is also one of the failure modes that automated testing tools frequently miss. The tools can detect that an accessible name exists. They generally cannot determine whether the accessible name contains the visible label text, especially when hidden elements are involved. Research on testing methodology gaps consistently shows that nuanced name-computation failures require human review to catch reliably.

The Fix

The correction principle is consistent across all three patterns: the accessible name must include the visible label text as a contiguous substring.

Fix for Pattern 1 — extend, don't replace:

<!-- PASSES: accessible name begins with visible label "Go" -->
<button id="sitesearch" aria-label="Go: Find in this site">Go</button>
<!-- BETTER: reconsider whether aria-label is needed at all -->
<button id="sitesearch">Go</button>

If the button's context makes "Go" sufficient — and in most cases it does — removing the aria-label entirely is cleaner. If additional context genuinely helps screen reader users, prepend or append it so the visible text is preserved within the accessible name.

Fix for Pattern 2 — don't interrupt the visible string:

<!-- PASSES: hidden text appended, not inserted mid-phrase -->
<a href="#">Download specification<span class="accessibly-hidden"> for the gizmo product</span></a>

Hidden supplemental text should come before or after the visible label, never inside it.

Fix for Pattern 3 — ensure the labelledby reference contains the visible value:

<!-- PASSES: hidden label text includes the visible value "search" -->
<span id="hidden-label" class="accessibly-hidden">search: Find in this site</span>
<input type="submit" aria-labelledby="hidden-label" value="search">

Or, better yet, reconsider whether aria-labelledby is the right tool here. A visible, descriptive button label often serves both populations better than a hidden override.

Applying This

Catching F96 in practice requires a combination of approaches:

In code review: Flag any aria-label or aria-labelledby usage on interactive controls. Ask: does the computed accessible name contain the visible text? The ARIA Authoring Practices Guide (opens in new window) provides guidance on when these attributes are appropriate. When reviewers see hidden spans injected into link or button text, that's an immediate signal to check the accessible name computation.

In automated testing: Tools like axe-core will catch some Label in Name violations, but coverage is incomplete. Per the WCAG Understanding document for 2.5.3 (opens in new window), the criterion applies whenever a UI component has both a visible text label and a programmatic name — automated tools can struggle with the contiguity requirement in Pattern 2 specifically.

In manual testing: Use browser DevTools accessibility panels (Chrome, Firefox, Safari all expose computed accessible names) to compare visible text against computed names on every interactive element. This takes minutes per page and catches what automation misses. The gap between automated and manual detection rates is substantial — research into hybrid testing methodologies makes clear that F96-class failures are precisely the type that require human judgment.

In design: When designers add supplemental label text for accessibility, establish a convention: supplemental text extends the visible label, it doesn't replace it. Document this in your design system's accessibility annotations.

CORS Perspective

From a community impact lens, F96 represents a category of exclusion that's easy to overlook in accessibility reviews because it doesn't block visual access — the interface looks correct to everyone who isn't speaking to it. Speech input users, who include a significant portion of people with motor disabilities and upper-limb differences, encounter a wall that's invisible to developers and auditors alike. The operational challenge is real: this failure requires manual testing with actual speech input tools to catch consistently, which demands both time and expertise that many teams haven't built. The strategic argument for fixing it is straightforward — the corrections are low-effort (reorder or extend text, don't replace it), the impact is high for affected users, and the risk exposure under WCAG 2.5.3 (opens in new window) is clear and documented. Teams that have invested in aria attributes to improve screen reader access should audit whether those same attributes are inadvertently breaking speech input — the fix is almost always a one-line change.