F111: When Your Label Is Visible But Functionally Invisible

The W3C's WCAG 2.2 Failure F111 (opens in new window) describes a deceptively simple problem: a control has a visible label, but no accessible name. The label exists. Users without disabilities see it. Speech input users speak it. And nothing happens.

This is one of those failures where the visual experience and the technical reality have completely diverged — and the divergence is invisible to sighted, mouse-based testers.

The Failure

F111 documents the gap between visible and accessible labeling. The official W3C description frames it precisely: "speech input users won't be able to activate the control using its visible label." Three success criteria fail simultaneously:

• 1.3.1 Info and Relationships (opens in new window) — the semantic relationship between the label text and the input isn't programmatically expressed
• 2.5.3 Label in Name (opens in new window) — the accessible name must contain the visible label text; if there's no accessible name at all, this criterion fails completely
• 4.1.2 Name, Role, Value (opens in new window) — every user interface component must have a name that assistive technologies can expose

The source document provides two distinct code examples, both worth examining because they represent different failure modes.

Example 1 — No accessible name at all:

<p>Enter name</p>
<input type="text">

The text exists. The input exists. The relationship between them exists only in the visual layout — not in the DOM.

Example 2 — A broken aria-labelledby reference:

<p id="nameEntry">Enter name</p>
<input type="text" aria-labelledby="name-entry">

This one is subtler and arguably more dangerous. A developer added aria-labelledby, which looks like a fix. But the id on the paragraph is nameEntry and the aria-labelledby references name-entry — a hyphen versus camelCase. The IDs don't match. The accessible name resolves to nothing. A visual audit or a quick code scan might miss it entirely.

Why This Matters

Three distinct user populations hit this barrier in different ways.

Speech input users (Dragon NaturallySpeaking, Windows Speech Recognition) navigate by speaking the visible label text. "Click Enter name" should activate the field. With no accessible name, the speech engine can't map the spoken phrase to the control. The user either gets no response or has to resort to grid-based navigation — a slow, frustrating workaround that bypasses the entire point of speech input.

Screen reader users encounter an unlabeled input. Depending on the browser/AT combination, they may hear "edit text" or the input's type attribute — no context about what the field is for. In a multi-field form, this is disorienting. In a checkout flow or medical intake form, it's a functional barrier.

Voice control and switch access users face similar mapping failures. The accessible name is the hook that connects visible UI to the assistive technology's control model. No name, no hook.

The broken aria-labelledby case (Example 2) deserves special attention: it fails silently. A developer added ARIA markup with apparent intent to fix the problem. Automated tools may flag the missing label on Example 1 — but a mismatched ID reference in Example 2 requires a tool that validates aria-labelledby targets against actual DOM IDs. Our research on automated testing limitations shows that automated tools catch at most 37% of accessibility failures. Broken ID references sit squarely in that 63% gap.

The Fix

The correct patterns are well-established. The HTML specification's native <label> element remains the most robust solution:

<!-- Explicit label association -->
<label for="user-name">Enter name</label>
<input type="text" id="user-name">

The for attribute value must exactly match the input's id. This creates a programmatic relationship that satisfies 1.3.1, 2.5.3, and 4.1.2 simultaneously. It also provides a click target bonus — clicking the label text focuses the input.

If the visual design requires a different structure (label wrapping the input, for instance):

<!-- Implicit label association -->
<label>
  Enter name
  <input type="text">
</label>

If aria-labelledby is genuinely necessary (referencing text elsewhere in the DOM), the ID match must be exact:

<!-- aria-labelledby: IDs must match exactly -->
<p id="nameEntry">Enter name</p>
<input type="text" aria-labelledby="nameEntry">

Note that nameEntry appears identically in both the id and aria-labelledby attributes. The failure in Example 2 was a single character difference — a hyphen — that broke the entire association.

For cases where a visible label isn't possible (icon-only buttons, search fields with placeholder text only), aria-label provides a direct string:

<input type="search" aria-label="Search products">

But when a visible label already exists, aria-label should match or contain that visible text — otherwise you've created a different 2.5.3 failure where the accessible name and the visible label diverge.

Applying This

In code review: Add a checklist item: every <input>, <select>, <textarea>, and interactive control must have either a <label for> match, an aria-labelledby pointing to a real, existing DOM ID, or an aria-label. Make ID matching a specific review point — not just "does aria-labelledby exist" but "does the referenced ID actually exist in this DOM?"

In automated testing: Tools like axe-core will catch Example 1 (no label at all). The broken ID reference in Example 2 is trickier — verify your toolchain validates aria-labelledby target resolution, not just attribute presence. Our research on hybrid testing methodologies argues for pairing automated scans with targeted manual checks precisely because broken references like this slip through.

In design handoff: If a designer marks up a label in a Figma component, the developer needs explicit instruction that the visual proximity of text to an input is not sufficient — the association must be encoded. Design systems that include pre-built, correctly labeled form components reduce this failure surface significantly.

Quick audit check: Open DevTools, inspect any form input, and run document.querySelector('input').labels in the console. If it returns an empty NodeList and there's no aria-label or valid aria-labelledby, you have an F111 failure.

CORS Perspective

Through the CORS framework, F111 sits cleanly in the Operational quadrant — this is a capacity and process failure more than a knowledge failure. Most development teams know labels matter. What breaks down is the implementation detail: ID matching precision, the difference between visual proximity and programmatic association, and test tooling that validates references rather than just attribute presence. The compliance framework research shows that organizations often focus on having accessibility processes rather than validating them — and a broken aria-labelledby is exactly the kind of failure that passes a checkbox review while blocking real users. The fix is a design system investment: pre-built, pre-validated form components that encode correct labeling by default, removing the per-developer decision from the equation entirely.