The autocomplete-valid rule flags form fields whose autocomplete attribute holds a value the HTML standard does not define – firstname instead of given-name, phone instead of tel, or nope to switch autofill off. Browsers and assistive technology ignore a value they do not know. The fix is the correct token from the HTML autofill list.
What the rule means
WCAG 1.3.5 asks that a field collecting information about the user – name, email, phone, address, date of birth – says what it is for in a way software can read. On the web that is the autocomplete attribute with one of the purposes WCAG lists, which come from the HTML autofill field names. Then a browser can fill it in, and tools can show a familiar icon or wording beside it.
The rule reads every <input>, <select> and <textarea> that has a non-empty autocomplete attribute, and skips disabled and read-only fields, hidden inputs and buttons. A value passes when it is:
onoroff,- one purpose token, such as
given-name,email,postal-codeorone-time-code, - optionally preceded by
section-…, thenshippingorbilling, then – only beforetel,emailorimpp–home,work,mobile,faxorpager, in that order.
axe also tolerates a few non-standard values that sites use to switch autofill off, such as none or false. A handful of values that are not in the standard – text, gender, pronouns, message, content – it does not decide; they come back for a person to review.
What the rule cannot see is whether a valid token is the right one. autocomplete="email" on the "Name" field passes. So does a field about the user with no autocomplete at all. Both are judgements, which is why the fact box above says "partly".
Who is affected
People with cognitive disabilities or memory difficulties, for whom typing an address again is a real barrier and autofill removes it. People with motor impairments, for whom every keystroke costs effort. People using tools that add familiar symbols to fields they recognise. And everybody filling in a checkout on a phone.
Why the check fails
- Invented tokens that look plausible:
firstname,lastname,phone,zip,mobile,birthday. - Random values to defeat autofill –
autocomplete="nope"or"new-field"– copied from forum answers. - Tokens in the wrong order, such as
billing section-1 postal-code, or two purposes in one value, such asname email. - A qualifier on the wrong token –
work nameormobile postal-code;home,workandmobilebelong only beforetel,emailorimpp. - Form builders and shop plugins that write a field's internal name into
autocomplete.
How to fix it
- For every field about the user, look up the purpose in the HTML autofill list [4] and use that token exactly.
- Combine only in the allowed order:
section-…, thenshipping/billing, thenhome/work/mobile, then the purpose. - To switch autofill off on a field that is not about the user – a coupon code, a search box – use
off, not an invented value.
<!-- Before: none of these tokens exist -->
<label for="first-name">First name</label>
<input id="first-name" name="fname" autocomplete="firstname">
<label for="phone">Mobile number</label>
<input id="phone" type="tel" name="phone" autocomplete="mobile phone">
<label for="email">Email</label>
<input id="email" type="email" name="email" autocomplete="nope"><!-- After: valid tokens, in the allowed order -->
<label for="first-name">First name</label>
<input id="first-name" name="fname" autocomplete="given-name">
<label for="phone">Mobile number</label>
<input id="phone" type="tel" name="phone" autocomplete="mobile tel">
<label for="email">Email</label>
<input id="email" type="email" name="email" autocomplete="email">
<label for="ship-zip">Postcode</label>
<input id="ship-zip" name="ship-zip" autocomplete="shipping postal-code">How to test it manually
- List the fields that ask for information about the person filling in the form – name, contact details, address, date of birth, username.
- In the developer tools, check each one has an
autocompletevalue, and that the value matches what the field asks for. - Fill the form with your browser's saved address and payment details. Fields left empty, or filled with the wrong data, point to a missing or wrong token.
- Check split fields, such as first and last name or day, month and year: each needs its own token (
given-name,family-name,bday-day, …).
Related WCAG criterion
1.3.5 Identify Input Purpose, Level AA. Related: 3.3.7 Redundant Entry, which asks that people are not made to type the same information twice in one process, and 3.3.2 Labels or Instructions – autocomplete helps software; the visible label is still what people read.
How Reviseberg reports it
Reviseberg runs autocomplete-valid on every crawled page at 1280px. The issue list shows the rule with its severity, WCAG criterion and level, the number of fields and pages affected, and the points you get back by fixing it. The detail view gives the CSS selector, the HTML snippet with the invalid value and every page affected – a checkout or newsletter form is usually one component, so one fix clears all of it.
Values axe does not decide go to the Potential issues queue for a person to review, instead of being counted as a pass. You can mark findings as "ignore", "can't fix" or "false positive" with a reason; every decision is logged. A clean result never marks 1.3.5 as passed: whether each field about the user has the right token is a person's check.