Level AA

Without an autocomplete token, a user-info input is opaque to browser autofill, password managers, and symbol-substitution assistive tech

1.3.5 Identify Input Purpose

In Plain Language

1.3.5 Identify Input Purpose (Level AA, new in WCAG 2.1) requires that any input field collecting information about the user -- name, email, phone, street address, postal code, payment details, birthdate, username, password -- expose that purpose programmatically[1]. In HTML, the mechanism is the autocomplete attribute populated with one of the named tokens from the WHATWG HTML spec[2].

Without the token the field is an opaque text input: the browser, password manager, and any assistive tool reading the DOM have no way to know it is asking for a telephone number rather than an order reference.

Why It Matters

  • Browser autofill and password managers key off autocomplete. When the token matches, the field pre-fills from stored values; when it is missing or wrong, the user types every character by hand. For users with motor impairments, tremor, or limited hand mobility, that is the difference between a form that takes seconds and one that takes minutes.
  • Symbol-substitution and icon-augmentation assistive tech read the token. Tools built for users with cognitive and learning disabilities use the autocomplete value to swap text labels for familiar symbols (phone handset, envelope, house) or to populate the field from a stored personal profile. If the token is absent the tool cannot identify the field and the augmentation does not happen[1].
  • Users with memory and language disabilities avoid recalling stored details. Postal codes, phone numbers, and full street addresses are exactly the data that autofill removes from working memory. The mechanism only works if the token is present.
  • Do not conflate 1.3.5 with 1.3.6 Identify Purpose. 1.3.6 is Level AAA and extends the programmatic-purpose requirement to UI components, icons, and regions beyond user-info inputs[3]. 1.3.5 is narrower: it covers the specific list of user-information input purposes enumerated in the WCAG 2.2 Recommendation.

Examples

Do: Autocomplete on personal info fields

✔ Fields use autocomplete -- browsers and assistive tech can identify their purpose

<label for="name">Full Name</label>
<input id="name" autocomplete="name">

<label for="email">Email</label>
<input id="email" type="email"
       autocomplete="email">
Don't: No autocomplete on user fields

✘ No autocomplete -- browsers cannot identify the purpose of these fields

<!-- FAILS: no autocomplete on user info fields -->
<label for="f1">Full Name</label>
<input id="f1">

<label for="f2">Email</label>
<input id="f2" type="email">
<!-- Browsers have to guess what these fields are -->
Do: Full address form with autocomplete

✔ Each field identifies its purpose -- enabling autofill across the entire form

<label for="street">Street</label>
<input id="street"
       autocomplete="street-address">

<label for="zip">ZIP Code</label>
<input id="zip" autocomplete="postal-code">

<label for="tel">Phone</label>
<input id="tel" type="tel"
       autocomplete="tel">
Don't: Wrong autocomplete values

✘ Autocomplete values do not match the actual field purpose -- confuses autofill and assistive tech

<!-- FAILS: autocomplete values are wrong -->
<label for="phone">Phone Number</label>
<input id="phone" type="tel"
       autocomplete="email">

<label for="addr">Email Address</label>
<input id="addr" type="email"
       autocomplete="street-address">
<!-- Values must match the actual field purpose -->

How to Fix It

  1. Add autocomplete to every field that collects information about the user. The normative list of purposes lives in WCAG 2.2 Section 7: Input Purposes for User Interface Components[3]. Token definitions and parsing rules are in the WHATWG HTML autofill section[2].
  2. Pick the correct token for the field's actual data. Common tokens include name, given-name, family-name, email, tel, street-address, address-level1, address-level2, postal-code, country, bday, cc-number, cc-exp, new-password, and current-password. For shipping and billing splits, prefix with shipping or billing (for example, autocomplete="shipping postal-code").
  3. Do not ship autocomplete="off" on user-info fields. The attribute still serialises into the DOM, but the value off tells the browser and assistive tech that the field has no programmatic purpose. That fails 1.3.5 and blocks password managers. Reserve autocomplete="off" for fields that are genuinely not about the user, such as a search input or a one-time verification code.
  4. Match token to semantics, not to label text. A field labelled "Mobile" still uses autocomplete="tel", not autocomplete="mobile" (which is not a valid token). Mismatched tokens such as autocomplete="email" on a phone input break autofill silently and confuse symbol-substitution assistive tech.
  5. Audit every form that collects user data. Login, registration, checkout, profile, and contact forms are the usual offenders. Check that each input with a defined user-info purpose carries the correct token, and that no legitimate user-info field has autocomplete="off".
  6. 1.3.5 is narrower than 1.3.6. If the scan also flags 1.3.6 Identify Purpose (Level AAA), that is a separate, broader obligation covering UI components and regions beyond user-info inputs -- fix 1.3.5 first[3].

References

  1. [1] W3C (2023). Understanding Success Criterion 1.3.5: Identify Input Purpose. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html ↩ ↩
  2. [2] WHATWG (2026). HTML Living Standard -- Autofill. WHATWG, Accessed 2026-04-07. https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill ↩ ↩
  3. [3] W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C, Accessed 2026-04-07. https://www.w3.org/TR/WCAG22/ ↩ ↩ ↩