Autocomplete Attributes: The One-Line Fix for WCAG 1.3.5

The checkout form has fourteen fields and not one of them tells the browser what it is for. The name field is a text input. The email field is a text input. The card number field is a text input. A password manager looking at that form sees fourteen identical boxes and guesses, and it guesses wrong often enough that the shopper ends up typing everything by hand. WCAG 1.3.5, Identify Input Purpose, is the criterion for this, and the fix is one attribute per field.

What 1.3.5 asks for

The criterion is Level AA, and it applies to input fields that collect information about the user: name, email, phone, address, payment details. The purpose of each input must be programmatically determinable, which in practice means the autocomplete attribute with the right token from the HTML specification's list: given-name, family-name, email, tel, street-address, postal-code, cc-number, cc-exp, and the rest. The token list is long and specific, and using the wrong token is worse than using none, because a wrong token makes the browser fill the wrong value with confidence.

The benefit is not theoretical. A shopper with a cognitive disability who cannot remember or retype their address gets it filled correctly. A shopper using a switch device, who pays for every keystroke in time and effort, gets fourteen fields filled in one action. A shopper on a phone gets the right keyboard for the field: email gets the @ key, tel gets the number pad, cc-number gets the numeric keyboard. The attribute is doing three jobs at once, and the form that lacks it is making all three harder.

The fields that fail it most

Payment fields fail most often, because payment forms are where custom components replace native inputs. A card number field built as a div with a contenteditable attribute, or a set of four separate boxes for the four groups of digits, has no autocomplete token at all, and no password manager can fill it. The fix is to use a real input with autocomplete set to cc-number, and to let the browser do the formatting. Expiry is the second failure: a single text field with autocomplete cc-exp-month and cc-exp-year split across two inputs is the pattern, and a single free-text field labeled MM/YY with no token is the failure.

Address fields fail in a quieter way. A form that asks for street, city, and postcode as three unlabeled text inputs, with no autocomplete tokens, forces the browser to guess from the labels, and labels like Address line 1 are not enough for a reliable guess. The tokens exist for exactly this: street-address for the street, address-level2 for the city, postal-code for the postcode. A form that uses them gets filled correctly by every password manager and every browser. A form that does not gets filled wrong, and the shopper blames the browser.

The test with a password manager

Open the form with a password manager enabled and a saved identity, and watch what fills. If the name lands in the email field, or the card number lands in the name field, or nothing fills at all, the form fails 1.3.5. Then check the HTML: every input that collects user information should carry an autocomplete attribute with the correct token, and the tokens should match the fields they sit on. The test takes two minutes and it finds the failure that a visual review never will, because the form looks fine. It looks fine because the failure is invisible until someone tries to fill it without typing. For the error side of the same form, see why color alone never says error, and for the checkout flow that wraps the form, the keyboard-only checkout test.

Frequently asked questions

What level is 1.3.5, and does it apply to AA targets?

Level AA. It is one of the 24 AA criteria in WCAG 2.2, so it sits inside every AA conformance target. A form that collects user information without autocomplete tokens fails AA.

Does the autocomplete attribute help sighted users too?

Yes. It drives the right keyboard on mobile, lets password managers fill the form in one action, and lets browsers offer the right autofill suggestions. The criterion is written for assistive technology, but the benefit is universal.

What happens if I use the wrong token?

The browser fills the wrong value with confidence, which is worse than filling nothing. A cc-number token on a phone field puts a card number where a phone number belongs. Use the exact token for the field, from the HTML specification's list.

Do custom payment components need autocomplete too?

Yes, and that is where they fail most. A card number built as a div or as four separate boxes has no token at all. Use a real input with autocomplete set to cc-number, and let the browser handle the formatting.