F68: When Forms Speak to No One

"The name can be provided in multiple ways," the W3C document notes, almost gently. Then it catalogs three distinct patterns where developers get this wrong anyway.

That tension — multiple correct paths, still failing — is what makes WCAG Failure F68 (opens in new window) worth understanding deeply. It's not a single mistake. It's a category of mistakes, all producing the same result: a form control that assistive technology cannot name.

The Failure

F68 documents violations of WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (opens in new window). The criterion requires that every user interface component have a name that can be programmatically determined — meaning assistive technology can read it, announce it, and communicate it to the user.

The failure isn't about labels being absent from the screen. It's about labels being absent from the accessibility tree. Three code patterns from the official W3C document illustrate this distinction:

Pattern 1: Text adjacent to inputs, no <label> element

<form>
  First name: <input type="text" name="firstname"><br>
  Last name: <input type="text" name="lastname"><br>
  I have a dog <input type="checkbox" name="pet" value="dog">
  I have a cat <input type="checkbox" name="pet" value="cat">
</form>

Sighted users see "First name" next to the field. Screen reader users hear "edit text" — no name, no context.

Pattern 2: <label> elements present but unlinked

<form>
  <p>
    <label>First Name</label>
    <input type="text" name="firstname">
    <label>Last Name</label>
    <input type="text" name="lastname">
  </p>
</form>

This one is more insidious. The <label> element is there. The developer probably thought they were done. But without a for attribute matching the input's id, the association is visual, not programmatic. The accessibility tree sees two unrelated elements.

Pattern 3: Search field with placeholder text only

<input type="text" value="Type your search here">
<input type="submit" value="Search">

Placeholder text is not an accessible name. It disappears when users start typing. Screen readers handle it inconsistently. This pattern fails F68 directly.

Why This Matters

When a form control has no programmatically determined name, screen reader users encounter a void. NVDA might announce "edit" or "checkbox" — the role without the label. JAWS might read the name attribute, which is a development convention, not a user-facing label. VoiceOver on iOS may read surrounding text, or it may not.

The experience isn't uniformly broken — it's unpredictably broken. That inconsistency is its own barrier. A screen reader user navigating a form with unlabeled fields must guess, backtrack, and cross-reference context clues to understand what each field is asking. On a simple two-field form, this is annoying. On a multi-step checkout, insurance enrollment, or benefits application, it's a genuine exclusion from a process that may have no alternative path.

Switch access users face the same gap — their software reads the accessibility tree, not the visual layout. Voice control users trying to say "click First Name" find nothing to target if the field has no name.

The checkbox pattern in Example 1 deserves specific attention. Checkboxes without labels are particularly disorienting because their purpose is binary — but "what am I agreeing to?" is the entire question. An unlabeled checkbox is an unsigned contract.

The Fix

The W3C document specifies several valid approaches. The most semantically clean is the for/id pairing:

<form>
  <label for="firstname">First Name</label>
  <input type="text" id="firstname" name="firstname">
  <label for="lastname">Last Name</label>
  <input type="text" id="lastname" name="lastname">
  <label for="dog">I have a dog</label>
  <input type="checkbox" id="dog" name="pet" value="dog">
  <label for="cat">I have a cat</label>
  <input type="checkbox" id="cat" name="pet" value="cat">
</form>

For cases where a visible label isn't practical — icon buttons, search fields in constrained layouts — aria-label provides a direct text name:

<input type="text" aria-label="Search" placeholder="Type your search here">
<input type="submit" value="Search">

Or aria-labelledby when the label text already exists elsewhere on the page:

<h2 id="search-heading">Site Search</h2>
<input type="text" aria-labelledby="search-heading">

The W3C document notes that submit buttons (<input type="submit">), reset buttons, image buttons, and <button> elements get their names differently — from the value attribute, alt attribute, or element content respectively. Those element types don't use <label>. The failure pattern applies specifically to <input>, <textarea>, and <select> elements that need explicit label association.

Applying This

F68 violations are partially detectable by automated tools — axe-core and similar engines can flag inputs with no computed accessible name. But as our research on automated testing methodology shows, automation catches at most 37% of real-world accessibility failures. F68 falls into the detectable category more often than most issues, but Pattern 2 — labels present but unlinked — can slip through tools that check for label presence without verifying association.

For development teams, the highest-leverage intervention is a design system rule: every form input component should require a label prop, with a build-time warning when it's missing. This shifts the catch from QA to authoring time. Storybook accessibility add-ons can surface axe violations during component development, before the pattern propagates across a codebase.

Code review checklist items worth adding:

• Every <input>, <textarea>, and <select> has either a linked <label> (via for/id) or an ARIA label attribute
• id values used for label association are unique on the page (duplicate IDs break the association)
• Placeholder text is never the only label source
• Icon-only buttons have aria-label or visually hidden text

For teams managing multilingual deployments, the label problem compounds. A programmatically correct label in English becomes inaccessible the moment the page is translated if the accessibility layer — ARIA labels, alt text, validation messages — isn't translated alongside the visible text. Tools like idioma.chat (opens in new window) address this directly: they translate the full accessibility layer, not just the visible page content. An aria-label="Search" that stays in English on a Spanish-language page is the same failure as no label at all, just in a different language. The unlabeled form field and the untranslated ARIA attribute are the same barrier wearing different clothes.

This connects to a broader question worth sitting with: how much of what we call "accessibility compliance" is actually just English-language accessibility? The compliance framework analysis on this site documents how organizations often treat WCAG as a technical checklist without considering the population actually using their forms. A screen reader user who speaks Vietnamese needs a Vietnamese aria-label, not just a programmatically present one.

CORS Perspective

From an operational capacity standpoint, F68 is one of the more fixable WCAG failures in a developer's toolkit — the correct patterns are well-documented, the tooling to catch violations exists, and the fix is typically a few attributes rather than an architectural change. The real operational challenge is scale: a codebase with hundreds of form components built before accessibility was a design system concern requires systematic remediation, not just spot fixes. Teams that haven't yet embedded label requirements into their component library should treat that as the priority investment — it's the intervention that prevents the next thousand F68 instances from being written. The settlement trap research on this site documents what happens when organizations fix symptoms without fixing the systems that produce them.