WCAG 1.3.5 requires that form fields that collect a visitor's own details, such as name, email, phone number or address, declare their purpose in code, which in HTML means the right autocomplete value on each field. This AA requirement arrived in WCAG 2.1 and makes autofill work for people who find typing slow or error prone.
Here you will find which fields are in scope, a table of common values, who benefits, markup without and with purpose, audit findings and a test routine. For the rest of the 2.1 additions, see WCAG 2.1 AA.
Quick facts
Level
AAAdded in
WCAG 2.1Principle
Perceivable, guideline 1.3 AdaptableApplies to
Fields that collect the user's own data and match a WCAG input purposeHTML fix
autocomplete="email","tel","given-name"and so onFast test
Inspect each personal field for a valid autocomplete value
WCAG 1.3.5 in one minute
Your form asks for an email address. A sighted person reads the label and knows. Software only knows if you tell it, and HTML has a standard way to do that: the autocomplete attribute with an agreed value such as email. Once the purpose is in the code, the browser can fill the field from saved details, and tools that personalise pages can add a familiar icon or simpler wording next to it.
Version 2.1 introduced it, at the AA tier. It is one of the easiest AA criteria to fix: often a single attribute per field, with no visual change.
Which inputs the rule covers
Two conditions must both be true for a field to be in scope:
- It collects information about the user, the person filling in the form. A gift recipient's address or an emergency contact's phone number is not in scope, though adding autocomplete there does no harm if the value fits.
- Its purpose is on the WCAG list. W3C publishes a fixed list of input purposes in the standard itself. A field asking for a favourite color or an order number is not on it, so the rule does not apply.
Search fields, message boxes and coupon codes are outside the rule. Do not invent values for them; a wrong value is worse than none, because autofill may paste the wrong data.
Common autocomplete values for personal fields
| Field asks for | autocomplete value |
|---|---|
| Full name | name |
| First or given name | given-name |
| Last or family name | family-name |
| Email address | email |
| Phone number | tel |
| Full street address in one box | street-address |
| First address line | address-line1 |
| Town or city | address-level2 |
| Postal code, ZIP or PIN code | postal-code |
| Country name | country-name |
| Date of birth | bday |
| Company name | organization |
| Username | username |
| New password at sign up | new-password |
| Password at sign in | current-password |
The full list in the standard has many more, including split parts of a phone number and a birthday. Use exactly the spelling shown; values are lowercase and hyphenated.
People who gain from autofill and labelled purposes
- People with motor disabilities who type slowly with a switch, a head pointer or one finger save a great deal of effort when fields fill themselves.
- People with memory or cognitive disabilities do not have to recall a postal code or spell an email address correctly.
- People with dyslexia avoid typos in fields where one wrong letter breaks the result.
- Users of personalisation tools can see their own symbols beside fields, because the purpose is machine readable.
- Everyone on a phone gets faster checkout, which is why this rule is popular with product teams too.
Sign-up form markup: without and with purpose
Fails: labels are fine for people, but nothing tells the browser what each field means, and autofill is switched off.
<label for="fn">First name</label>
<input id="fn" type="text" autocomplete="off">
<label for="em">Email</label>
<input id="em" type="text">Passes: each field states its purpose with a standard value.
<label for="fn">First name</label>
<input id="fn" type="text" autocomplete="given-name">
<label for="em">Email</label>
<input id="em" type="email" autocomplete="email">The type="email" is good practice for the phone keyboard, but it does not meet the rule by itself. The autocomplete value is what counts. Labels are still required by the labels and instructions rule.
Typical audit findings for input purpose
| Finding | Why it fails | Repair |
|---|---|---|
| No autocomplete on name, email or phone | Purpose cannot be read by software | Add the matching value |
autocomplete="off" on personal fields | Purpose hidden and autofill blocked | Replace with the correct value |
Wrong value, such as name on a last name field | Autofill puts the full name in | Use family-name |
Made-up value like autocomplete="phone" | Not a valid token, so ignored | Use tel |
| Value on the wrong element, such as the label or a div | Browsers only read it on form fields | Move it to the input, select or textarea |
| Custom field built from a div with contenteditable | No standard way to state purpose | Use a native input |
Checking 1.3.5 wcag on a form
- Find the personal fields. List every input that asks the visitor about themselves: name, email, phone, address, birthday, username and password.
- Skip the rest. Leave out fields about other people, search boxes, comments and anything not on the WCAG list of input purposes.
- Inspect the attribute. In developer tools, check that each personal field has an autocomplete attribute with a valid value.
- Match value to meaning. Confirm the value fits the question, for example given-name on a first name field and not name or email.
- Try real autofill. Save your details in the browser, reload the form and confirm the browser offers to fill each field correctly.
Most automated checkers flag invalid autocomplete values, but they cannot know that a field labelled Surname needs family-name. Step four always needs a person.
Questions people ask
What does 1.3.5 wcag require for forms?
Fields that collect the user's own details, such as name, email, phone and address, must state their purpose in code. In HTML you do that with the autocomplete attribute and a value from the WCAG list. Its level is AA; version 2.1 brought it in.
Is autocomplete off a failure of 1.3.5?
On fields about the user, auditors usually log it as a failure, because the purpose is no longer identified and autofill is blocked. On fields outside the list, such as a one time code, it is not covered by this rule.
Do I need autocomplete on a search box?
No. Search is not one of the input purposes in WCAG, so the rule does not apply. Leave it out rather than adding a wrong value.
Does 1.3.5 apply to fields about another person?
No. It covers only information about the person filling in the form. Fields for a recipient, a child or an emergency contact are outside the rule.
Is the name attribute enough to show purpose?
No. The name attribute is for the server and has no agreed meaning. Browsers and assistive tools read the autocomplete attribute.
Which version of WCAG added identify input purpose?
WCAG 2.1 added it, at Level AA. It is unchanged in WCAG 2.2, so targets based on either version include it.