F107: When Autocomplete Attributes Lie to Assistive Technology

When the HTML 5.2 specification codified the autocomplete attribute's fixed token list, it created something rare in web standards: a machine-readable vocabulary for human identity. A browser — or a password manager, or an AAC device, or an autofill extension built for users with motor disabilities — could finally know that a field collects a street address, not just guess from a label that says "Address."

WCAG 2.2 Failure F107 (opens in new window) documents what happens when developers ignore that vocabulary. The result is form inputs that claim to be something they're not — and assistive technology that has no choice but to believe them.

The Failure

F107 describes a specific failure of Success Criterion 1.3.5 Identify Input Purpose (opens in new window), which requires that inputs collecting information about the user can be programmatically determined. The failure occurs in two distinct ways: using a valid token on the wrong field, or inventing a token that doesn't exist in the specification at all.

The W3C's canonical example makes both mistakes visible in a single form:

<!-- FAILING PATTERN -->
<h2>Your details:</h2>
<label for="uname">Name:</label>
<input autocomplete="email" id="uname" type="text">
<label for="ubirthday">Birthday:</label>
<input autocomplete="birthday" id="ubirthday" type="text">

Two problems, two different failure modes. The name field carries autocomplete="email" — a valid token, but the wrong one. The birthday field carries autocomplete="birthday" — which simply doesn't exist in the HTML specification. The correct values are name and bday respectively.

Neither error will trigger a visible UI problem. The form renders fine. A sighted user with no assistive technology fills it out without incident. The failure is entirely in the metadata layer — which is precisely where disabled users depend on the web to work correctly.

Why This Matters

The people SC 1.3.5 protects aren't an edge case. They're users who rely on autofill because typing is painful, slow, or impossible. Users with dyslexia who benefit from browser-assisted form completion. Users running AAC software that can populate fields automatically. Users with cognitive disabilities who struggle to remember which field wants which information when visual labels aren't sufficient context.

When autocomplete="email" appears on a name field, a browser's autofill engine may inject an email address into a name field — silently, confidently wrong. The user may not catch it. The form may submit with corrupted data. The downstream consequence could be a failed transaction, a rejected application, or an account created under the wrong name.

The invented birthday token is a different kind of harm. Browsers and assistive technologies that parse autocomplete values for semantic meaning encounter an unknown token and fall back to treating the field as generic text input. The programmatic signal that SC 1.3.5 requires — the signal that would let a tool know this field wants a birth date — simply isn't there. The opportunity to assist the user is gone.

This is why automated testing tools catch only a fraction of real accessibility failures. A linter can flag autocomplete="birthday" as an invalid token. But correctly identifying that autocomplete="email" on a name field is semantically wrong requires understanding the field's purpose — context that automated tools rarely have.

The Fix

The corrected pattern is straightforward:

<!-- CORRECT PATTERN -->
<h2>Your details:</h2>
<label for="uname">Name:</label>
<input autocomplete="name" id="uname" type="text">
<label for="ubirthday">Birthday:</label>
<input autocomplete="bday" id="ubirthday" type="text">

The fix requires knowing two things: which fields on your form collect personal user information, and what the correct token is for each. The HTML Living Standard's autocomplete section (opens in new window) is the authoritative source. WCAG's Input Purposes for User Interface Components (opens in new window) maps directly to that token list.

One additional constraint from SC 1.3.5: the criterion applies to inputs scoped to the primary end user of the form. A form collecting a shipping recipient's name — someone other than the logged-in user — is not required to carry these tokens. The criterion is specifically about the user identifying themselves.

Applying This

The practical challenge here isn't the fix — it's detection. Invalid tokens don't break forms visually, so they survive QA cycles that focus on functional behavior. Three approaches catch them reliably:

In code review: Create a checklist item: any <input> collecting user personal data must have an autocomplete attribute, and that attribute must use a token from the WCAG Input Purposes list (opens in new window). Reviewers should verify both presence and correctness.

In automated testing: Tools like axe-core flag some invalid autocomplete values. Configure your CI pipeline to run these checks on every form-containing page. This catches invented tokens. It won't catch semantically misapplied valid tokens — that requires human review.

In design: Add autocomplete token requirements to your design system's form component documentation. When a designer specifies a "name field," the spec should include autocomplete="name". Catching this at the design stage costs far less than retrofitting production forms.

The compliance framework research we've published shows that organizations often treat WCAG 2.2 additions as lower priority than foundational criteria. SC 1.3.5 — added in WCAG 2.1 — still appears in audits as a gap. Building token validation into your standard development workflow is how you stop rediscovering the same failure.

CORS Perspective

Through a strategic alignment lens, F107 is a low-cost fix with disproportionate user impact — exactly the kind of issue that belongs on a team's "chop list." The operational lift is minimal: a reference to the HTML spec, a code review checklist item, a linter rule. The community impact lands hardest on users with motor disabilities, cognitive disabilities, and anyone who depends on autofill to participate in digital services without friction. From a risk standpoint, SC 1.3.5 is a Level AA requirement under WCAG 2.2, meaning it's within scope for Title II obligations (opens in new window) and any accessibility conformance claim your organization makes. The strategic case is simple: fixing this takes an afternoon; explaining why your form told a screen reader that a name field collects email addresses takes considerably longer.