Identify Input Purpose
A field collecting information about the person filling in the form has to declare what it is for, in code, using one of 53 defined purposes. In HTML that means the autocomplete attribute. The point is the declaration rather than the auto-filling. A field can carry autocomplete="email" on a form that suppresses autofill and still meet this rule, because the purpose is there to be read. Two limits keep the job small. The purpose has to be one of the 53, so a "how did you hear about us" box is out of scope. And the information has to be about the user. A gift recipient's address, an emergency contact's number and a referee's email all sit outside the rule, even though those purposes appear on the list.
Why it matters
The reason this rule exists is not the reason most people assume. Once a field declares what it holds, assistive technology can change how that field looks to the person filling it in. It can put a birthday cake on the date of birth and a telephone on the phone number, for somebody who reads symbols more easily than labels. The tokens mean the same thing in every language, so a user who cannot read your label still gets a field they recognize. Then there is the ordinary benefit. Every keystroke a form demands is friction, and for somebody with a motor or memory impairment that friction is often the difference between finishing checkout and giving up on it.
Who this rule protects
People with cognitive disabilities who cannot work out a field's purpose from the label alone are the group this rule was written for. People with cerebral palsy, stroke, head injury, motor neuron disease or a learning disability who use software that puts pictures on form fields depend on the same declaration. So do people with motor disabilities for whom typing is slow and effortful, people with memory difficulties, and anyone mistyping an address on a phone keyboard.
How to check it yourself
- List the fields collecting the user's own details and check each one carries a purpose token, such as autocomplete="name", autocomplete="email", autocomplete="tel", autocomplete="street-address" or autocomplete="postal-code".
- Check the token matches the field. An email token on a name field is a documented failure, and so is an invented token like "birthday" where the defined one is "bday".
- Check the token order, because the grammar is strict. An optional section token comes first, then shipping or billing. Then a contact type such as home or work, but only where the next token is email, impp, tel or one of the tel variants. Then the field token itself. The one thing allowed after it is webauthn, on a passkey field.
- On a checkout with two addresses, check the billing and shipping tokens are used to tell the two sets apart.
- Skip the fields that are not about the user. A recipient's address on a gift order needs nothing at all.
- Do not treat a successful autofill as proof. Browsers will fill fields whose tokens do not meet the grammar, so a form can autofill beautifully and still fail this rule.
Failures we see most often
- Checkout fields carry no purpose token at all, so nothing in the code says which one holds the user's own postal code.
- A field carries a token that does not match what it collects, such as an email token sitting on a surname field.
- A token is invented rather than taken from the defined list, so it means nothing to anything reading the form.
- Tokens are written in the wrong order, such as "email home" where the grammar requires "home email".
- Two group tokens are combined, such as "billing shipping street-address", which cancels the pair out and leaves the field undeclared.
- A form library ships with autofill switched off and no purposes declared, and nobody turns either one back on.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How this one is tested
We list 1 ACT rule against 1.3.5. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.
- Autocomplete attribute has valid valueA tool can check this
How to fix it
- Add the correct token to every field collecting a user's own personal data, matched to what the field actually asks for.
- Use the billing and shipping tokens on a two-address checkout, so both sets are identified and neither one overwrites the other.
- Keep the type attribute accurate as well. Setting type to email or tel brings up the right keyboard on a phone. Type alone never satisfies this rule, because it says what kind of data a field takes rather than whose data it is.
- Where a field genuinely accepts two purposes, such as a combined username and email box, pick one token or leave the purpose off. Both are allowed.
- For passkey flows, the webauthn token is part of the grammar and goes last in the list.
Step-by-step fix guides (2)
Passes vs. fails
Passes
An input with type email, name email and autocomplete email declares its purpose, so a browser can fill it and assistive technology can relabel it.
Fails
A field named fld_7 collects an email address and nothing in the code says so, so no tool can identify the field or adapt it.
In audits and lawsuits
This is about as machine-checkable as Perceivable gets, and the check is narrower than it sounds. A scanner can tell you whether a token is spelled correctly and ordered correctly. It cannot tell you that a field collecting the user's own phone number carries no token at all. It cannot tell you the token that is there is the wrong one for the field. Two things it deliberately skips. Values of off and on are excluded from the automated rule entirely, and so are disabled fields, buttons, checkboxes and radios. In our fix guidance this is a favorite quick win, because it is one attribute per field and we can confirm the fix on a retest in minutes.