WCAG 1.3.5: The Autocomplete Requirement That Actually Changes Lives

When the Web Content Accessibility Guidelines first introduced the autocomplete attribute as an accessibility mechanism in WCAG 2.1, the web development community largely treated it as a minor convenience feature. Four years later, with WCAG 2.2 carrying the requirement forward at Level AA, the pattern persists: teams implement autocomplete for UX polish, not because they understand what it actually does for users with cognitive disabilities, memory impairments, or motor limitations who struggle to complete forms independently.

That gap between implementation and understanding is exactly what Success Criterion 1.3.5: Identify Input Purpose (opens in new window) is designed to close.

THE REQUIREMENT

SC 1.3.5 (opens in new window) sits at Level AA under Principle 1 (Perceivable), Guideline 1.3 (Adaptable). Its requirement, stripped to essentials: when a form field collects information about the user — name, address, phone number, email, credit card data — and the technology supports it, the purpose of that field must be programmatically determinable.

The distinction between type and purpose is the heart of this criterion. HTML's type attribute has long provided broad category signals: type="email" tells browsers the field expects an email address. But it cannot distinguish between a field collecting your email address and one collecting a contact's email. It cannot tell assistive technology whether a name field wants a full name, a given name, or a family name. That granularity matters enormously when a user agent or assistive technology is trying to auto-populate fields on behalf of a user.

The mechanism for achieving this in HTML is the autocomplete attribute, which accepts a defined set of values from Section 7 of the WCAG 2.1 Recommendation (opens in new window). These values provide the fine-grained purpose declarations that type cannot. The single sufficient technique documented for this criterion is H98 (opens in new window), which covers using HTML autocomplete attributes with the specified token values. The documented failure mode is F107 (opens in new window): incorrectly using autocomplete attribute values.

<!-- Fails SC 1.3.5: type alone is insufficient -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email">
<!-- Passes SC 1.3.5: purpose is programmatically declared -->
<label for="email">Email Address</label>
<input type="email" id="email" name="email" autocomplete="email">
<!-- Granular purpose for name fields -->
<label for="fname">First Name</label>
<input type="text" id="fname" name="fname" autocomplete="given-name">
<label for="lname">Last Name</label>
<input type="text" id="lname" name="lname" autocomplete="family-name">

The criterion applies only when the field collects information about the current user and when the technology supports programmatic declaration. It does not apply to fields collecting information about third parties, and it does not require implementation where no standard mechanism exists.

WHY THIS MATTERS

The exclusion this criterion addresses is not subtle. Consider users with:

• Cognitive disabilities — including dyslexia, traumatic brain injury, or intellectual disabilities — who may not be able to reliably recall or correctly enter their own address, phone number, or credit card information without assistance
• Motor impairments — users who rely on switch access, eye tracking, or voice input, for whom each form field represents significant physical effort
• Memory impairments — users with early-stage dementia or acquired brain injuries who know their information but cannot reliably retrieve it on demand

For these users, browser autofill and assistive technology that can programmatically populate form fields is not a convenience — it is often the difference between completing a transaction independently and requiring help. When a field lacks proper autocomplete markup, that automation breaks. The browser cannot confidently match the field's purpose to stored data. The assistive technology cannot offer to fill it. The user is left to manage manually.

The W3C's intent documentation makes this explicit: the goal is enabling fields to be "rendered in an unambiguous, consistent, and possibly customized way for different modalities." Some users configure their systems to display icons or symbols alongside recognized field types. Others use tools that speak field purposes aloud before prompting input. All of these adaptations depend on the programmatic signal that autocomplete provides.

This is also a criterion where the community most directly affected — people with cognitive disabilities — is historically underrepresented in accessibility testing and user research. Forms that appear perfectly usable in standard audits can present significant barriers that only emerge in real-world use.

HOW TO MEET IT

The implementation path is straightforward. The WCAG input purposes list (opens in new window) defines 53 specific autocomplete token values covering personal data fields: names, addresses, phone numbers, email, payment information, and more.

<!-- Common personal information fields with correct autocomplete values -->
<input autocomplete="name">           !-- Full name -->
<input autocomplete="given-name">     !-- First name -->
<input autocomplete="family-name">    !-- Last name -->
<input autocomplete="email">          !-- Users email -->
<input autocomplete="tel">            !-- Phone number -->
<input autocomplete="street-address"> !-- Street address -->
<input autocomplete="postal-code">    !-- ZIP/postal code -->
<input autocomplete="cc-number">      !-- Credit card number -->
<input autocomplete="bday">           !-- Date of birth -->

The failure mode documented in F107 (opens in new window) — incorrect autocomplete values — is worth taking seriously. Using autocomplete="off" on fields that collect personal user information explicitly fails this criterion. So does using values that don't match the actual field purpose (labeling a credit card field with autocomplete="email", for instance).

A few implementation considerations that trip up teams:

• autocomplete="off" is not a neutral choice. On fields collecting personal information, it is an active failure of SC 1.3.5. Security concerns about autofill are legitimate but must be addressed through other means — not by disabling the accessibility mechanism entirely.
• Multi-page forms require consistency. If a checkout flow splits address collection across pages, each field still requires correct autocomplete markup on every page.
• Custom components need explicit handling. If your team has built custom input components that render <div> elements with ARIA roles instead of native <input> elements, the autocomplete attribute approach may not apply. This is a significant architectural risk.

APPLYING THIS

Automated testing catches some failures here — tools can flag missing autocomplete attributes on fields that match common patterns, and they can identify autocomplete="off" on personal information fields. But automation has real limits. As our research on testing methodology documents, automated tools detect at most 37% of accessibility failures in comprehensive audits. SC 1.3.5 is a good example of why: a tool can confirm an attribute exists, but it cannot reliably determine whether the value is correct for the field's actual purpose.

For development teams, the most effective approach combines:

In design: Add autocomplete value requirements to form field specifications. This should be a design artifact, not an afterthought in development.

In code review: Include a checklist item: does every field collecting personal user information have a correct autocomplete value from the WCAG input purposes list (opens in new window)? Is autocomplete="off" used anywhere on personal information fields?

In QA: Manual review of form fields against the WCAG token list. Test with browser autofill enabled to verify fields populate correctly. Test with screen reader software to verify purpose is announced.

In component libraries: If your organization maintains a design system, build autocomplete requirements into the component API. A <TextInput purpose="given-name" /> that enforces correct attribute values is more reliable than relying on individual developer knowledge.

Teams navigating multiple compliance frameworks — WCAG, Section 508, EN 301 549 — should note that SC 1.3.5 is incorporated into Section 508 through the WCAG 2.0 incorporation by reference (opens in new window), though the precise mapping warrants verification given the multi-standard complexity our research on compliance framework fragmentation documents.

CORS PERSPECTIVE

SC 1.3.5 illustrates a pattern visible across the CORS framework: a requirement with clear community benefit (cognitive accessibility, motor accessibility, independent form completion) that has low operational cost when built into development workflows from the start, but generates disproportionate remediation burden when retrofitted across legacy form libraries. The risk calculus is straightforward — Level AA means this is required for WCAG conformance claims and by extension for Title II and Title III compliance under the DOJ's web accessibility rules (opens in new window) — but the strategic opportunity is larger: organizations that implement this correctly demonstrate that accessibility and usability genuinely converge, building the internal case for accessibility investment that goes beyond legal obligation.