Identify Input Purpose

What it asks

For each of 53 specific user-information fields listed in WCAG (name, email, tel, street-address, cc-number, bday, country, etc.), the input must include the matching autocomplete token. The point isn’t browser autofill convenience — it’s that assistive tools (symbol-set keyboards, AAC apps, cognitive-support layers) can swap your form labels for icons, translations, or alternative inputs only when the field’s purpose is machine-readable.

How to meet it

• Add autocomplete="email" to email fields, autocomplete="given-name" to first-name, autocomplete="family-name" to last-name.
• Use autocomplete="tel" for phone, autocomplete="street-address", autocomplete="postal-code", autocomplete="country".
• For payment forms, use autocomplete="cc-name", cc-number, cc-exp, cc-csc.
• Reference the full list in the HTML spec — these tokens are normative.
• Combine with <input type="email">, type="tel">, type="url"> for correct on-screen keyboards.
• For non-personal fields (a search box, a custom rating), no autocomplete token is needed — the SC only covers the 53 personal-information types.

Common failures

• autocomplete="off" on the entire login form “for security” — actively prevents compliance and breaks password managers.
• Email field with no autocomplete token, so symbol-keyboard users can’t get a customized input.
• Address fields labelled “Address Line 1” but with no autocomplete="address-line1".
• Credit-card fields with custom JavaScript autocomplete instead of the native token.
• Sign-up form with name field collecting full name but no autocomplete="name".

Why it matters

This SC is widely missed because the failure isn’t visible — the form works for typical users, but adaptive-input users get a generic experience. Adding autocomplete tokens is a 30-minute task across most sign-up flows and improves typical-user UX (browser autofill works better) at the same time.