Search topics
Form fields that block or break autofill
A delivery form turns autofill off and uses made-up autocomplete values, so the browser can't tell which field wants a name, an email, a postcode or a phone number.
The problem
People who rely on autofill have to type their name, email, postcode and phone by hand, letter by letter.
A pharmacy lets people order a repeat prescription for delivery. The form asks for four things everyone knows by heart: full name, email, postcode and phone. Each field has a clear label, and a keyboard user can reach all of them. But when the person clicks into "Full name", the browser offers nothing. The saved name, email, address and number they use on every other site never appear, and the phone's suggestion bar stays empty. They type all four by hand, one letter at a time.
1.3.5 asks that the purpose of each field collecting information about the user can be determined by software. In HTML that is the autocomplete attribute, with a token from the list in the HTML standard. This form gives the browser nothing to go on. The form has autocomplete="off", which the phone field inherits, and the name field repeats it. The email field says autocomplete="e-mail" and the postcode field autocomplete="postcode": both look sensible, but neither is a token, so the browser ignores them. Browsers guess from the field's name and label, but a guess isn't a declared purpose, and it fails often.
Typing every detail by hand costs everyone time, and most on a phone, where the keyboard covers half the form.
3 of 10 groups affected
- No vision (not affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited reach and strength People with motor impairments, for whom each keystroke takes effort or pain, have to type every detail by hand.
- Limited language, cognitive and learning abilities People with memory or cognitive difficulties may not recall their postcode or phone number, or may mistype them. The same tokens let some tools show a familiar icon next to each field, which helps people who find text hard to read.
- Limited manipulation People who use voice input or a switch find typing an email address slow and error-prone.
axe's autocomplete-valid rule finds the made-up e-mail and postcode values. It accepts autocomplete="off", and it says nothing about a field with no attribute at all, so the name and phone fields pass. A generated fix often adds autocomplete="off" to "stop the browser suggestions", or copies the field's name into the attribute. Whether each token matches what the field really asks for, and whether a field asks about the user or about someone else, is something a person has to check.
Try it
Choose Simulate autofill, as if you picked your saved details from the browser.
Autofill can only fill a field that declares its purpose with a standard token. Under each field, see what the browser is told.
Broken Can you fix this?
A recreated demo. The broken version is intentionally inaccessible.
The fix
Tell the browser what each field is for, with the standard autocomplete token.
- 1Every field that asks for the user's own details has an autocomplete token for its purpose.
- 2Use only tokens from the HTML autofill list: tel, not phone; postal-code, not postcode.
- 3Don't turn autofill off for the user's own details, on the field or on the form.
<form autocomplete="off"> <label for="name">Full name</label> <input id="name" name="name" type="text" autocomplete="off"> <label for="email">Email</label> <input id="email" name="email" type="text" autocomplete="e-mail"> <label for="postcode">Postcode</label> <input id="postcode" name="postcode" type="text" autocomplete="postcode"> <label for="phone">Phone</label> <input id="phone" name="phone" type="text"></form><form> <label for="name">Full name</label> <input id="name" name="name" type="text" autocomplete="name"> <label for="email">Email</label> <input id="email" name="email" type="email" autocomplete="email"> <label for="postcode">Postcode</label> <input id="postcode" name="postcode" type="text" autocomplete="postal-code"> <label for="phone">Phone</label> <input id="phone" name="phone" type="tel" autocomplete="tel"></form>Every field is labelled, but none declares its purpose. Two are switched off, one inherits off from the form, and two use values that aren't in the HTML list.
Each field now names its purpose with a token from the HTML list, so the browser, a password manager or a phone keyboard can offer the right saved detail for each one, and fill the whole form in one step. The off on the form is gone, and the email and phone fields get the matching type, which also brings up the right on-screen keyboard.
Use the exact token. The list is fixed and short: name, given-name, family-name, email, tel, street-address, address-line1, address-level2 (town or city), postal-code, country-name, bday, organization, username, new-password, current-password, one-time-code and a few more. phone, zip, postcode and e-mail look right and do nothing.
Match the form's fields. If the form asks for first and last name separately, use given-name and family-name, not name twice. An address in several fields uses address-line1, address-line2, address-level2 and postal-code; one textarea for the whole address uses street-address.
Shipping and billing. When a form asks for two addresses, prefix each group: autocomplete="shipping postal-code" and autocomplete="billing postal-code". Without the prefix, autofill may put the same address in both.
Fields about someone else. 1.3.5 covers information about the user. A gift recipient's name, or a friend's email in a referral form, is not the user's, and filling it with their own details would be wrong. Leave those without a personal token. A delivery address for someone else still uses the shipping section, which exists for that case.
Search, codes and one-off fields. autocomplete="off" is fine on a search box or a field whose value should never be remembered, such as a captcha. For a one-time code sent by text, use one-time-code, so phones can offer the code from the message.
Components. Make autocomplete a prop of the shared field component, and have the email, phone and address variants set the right token and type by default. A hand-typed value that is one word off, as in the example, passes review unnoticed.
Verify the fix
4 checks, no mouse.
Test with: Autofill, Password manager, Touch
Record the OS, browser, password manager and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the shared field component changes.
Limits
This is a starting pattern, not a guarantee for every application. How each browser and password manager uses the tokens differs, and some ignore off on their own. 1.3.5 needs the purpose to be declared, not autofill to succeed everywhere. Fields inside payment iframes and third-party widgets need the same check by whoever controls them. Test the complete journey with the browsers and tools your users rely on.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.