Who does autocomplete help?
Typing is slow and tiring for many people. Someone with a tremor, arthritis or a repetitive strain injury may need several attempts to hit each key. Someone using a switch or an on-screen keyboard selects one letter at a time. Someone with dyslexia or memory loss may struggle to spell their own street name, or to remember their postcode while looking away from it. For all of them, a form that fills itself in from saved details turns minutes of effort into one tap.
Browsers and password managers already keep a contact card for most people: name, email, phone, address. They offer it when a field tells them what it is for. The autocomplete attribute is how a field tells them. WCAG 1.3.5 Identify Input Purpose, at level AA, asks for it on every field that collects information about the person using the form.
The benefit reaches everyone who fills a form on a phone, in a hurry, or with one hand. It also cuts typing errors, so fewer orders arrive with a misspelt email address.
How does the autocomplete attribute work?
The attribute takes a token from a fixed list in the HTML Living Standard. The browser matches that token against the details it has saved and offers them, usually as a dropdown under the field or as a bar above the phone keyboard. Picking one entry can fill every field on the form at once, because each field has declared what it wants.
Browsers also guess from the name and id attributes when autocomplete is missing, and those guesses are often wrong. A field called name on a form for a pet’s details may get your own name. A clear token removes the guesswork. It also lets assistive tools that show icons next to fields, which some people with cognitive disabilities use, show a phone icon next to the phone field.
The tokens can be combined with a section prefix: shipping postal-code and billing postal-code keep two addresses apart on one form.
<label for="fullname">Full name</label>
<input type="text" id="fullname" name="fullname" autocomplete="name">
<label for="postcode">Postcode</label>
<input type="text" id="postcode" name="postcode" autocomplete="postal-code">Which tokens do you need most often?
A small set covers most forms. Spell them exactly as listed, in lower case; a made-up token such as autocomplete="phone" is ignored and the field gets no help at all. Use given-name and family-name when the form has two name fields, and name when it has one. Use street-address for a single address box, or address-line1 and address-line2 when the street is split.
Passwords have their own tokens. Use current-password on a sign-in form and new-password on sign-up and change-password forms. Password managers use these to decide whether to fill a saved password or offer to generate a new one, and getting them right helps people who cannot memorise or retype long passwords, which ties to 3.3.8 Accessible Authentication.
name,given-name,family-nameemailtelstreet-address,address-line1,address-level2(town),postal-code,country-namebdayfor a date of birthusername,current-password,new-passwordone-time-codefor a code sent by text message
What do input types add?
The type attribute changes the keyboard a phone shows and what the browser checks. type="email" brings up a keyboard with @ and a dot within reach, and lets the browser warn about an address with no @. type="tel" opens a number pad with large keys, which helps people with limited dexterity. type="url" adds a key for slashes and .com. All three still accept any text that is typed or pasted, so nobody is locked out.
Screen readers announce most of these as an ordinary edit text, so the type changes little for them, though some say “email” or “telephone” in the role. The change is felt mostly by people on touch screens.
On the bakery form, the email and phone fields were plain text. After the fix, a phone user gets the right keyboard for each, and the browser offers saved values for the four personal fields. The **Checks** view no longer lists missing autocomplete.
<input type="email" id="email" name="email" autocomplete="email">
<input type="tel" id="phone" name="phone" autocomplete="tel">When is type="number" the wrong choice?
Use type="number" only for amounts you could add up or count, like the number of cakes. It adds small up and down arrows, accepts scroll wheel changes that can alter a value by accident, may drop leading zeros, and is announced by screen readers as a spin button, which suggests a value you step through.
Phone numbers, postcodes, card numbers, membership numbers and one-time codes are strings made of digits. Use type="tel" for phone numbers, and for the others use type="text" with inputmode="numeric". The inputmode attribute asks for a number keyboard without changing how the value behaves or how it is announced. It does nothing for validation, so pair it with pattern or a server check if the format matters.
UK postcodes contain letters, so the bakery postcode stays type="text" with no inputmode. A US ZIP code, digits only, could use inputmode="numeric".
<label for="card">Card number</label>
<input type="text" id="card" inputmode="numeric" autocomplete="cc-number">When should autocomplete be turned off?
Rarely. Turning it off for a person’s own details forces typing and breaks 1.3.5. Some sites switch it off on every field out of habit, or because a security checklist once said so, and most browsers now ignore autocomplete="off" on login fields anyway because blocking password managers made accounts less safe.
It makes sense on fields that are about something other than the person, where a saved value would be wrong. The message piped on a cake, a gift recipient’s name typed by a shop assistant, or a search box for someone else’s order number are fair cases. Even then, leaving the attribute out is usually enough: the browser may offer an earlier entry typed into the same field, but it has no saved contact detail to push in.
The 1.3.5 rule covers fields about the user. A bird sighting form asking “Where did you see it?” is not about the user and needs no token.
How do you check autocomplete here and in a real browser?
The **Checks** view flags fields whose name or id suggests personal details, like email, phone or postcode, when they have no autocomplete. It is a hint: it cannot tell whether your token is the right one, so read each one against the list.
The **Screen reader** view shows the role each type produces. A phone field announced as a spin button is a sign of type="number". In a real browser, save a contact address in the browser settings, open the page and focus the first field. The browser should offer that address, and picking it should fill every personal field in the right place. On a phone, check that the email and phone fields open the matching keyboard.
What do AI tools get wrong here?
Generated forms often leave out autocomplete, or add autocomplete="off" to the whole <form>, which blocks help on every field. They invent tokens like phone, zip or full-name, which browsers ignore silently. They also reach for type="number" for anything made of digits, giving phone numbers spinner arrows.
When you review the code, check each personal field for a token from the standard list, check that phone numbers are type="tel", and check that codes and card numbers use inputmode="numeric". Then fill the form once with the browser’s own suggestions to prove it works.
Field notes
- Autofill saves typing for people who find typing slow or tiring.
- The
autocompleteattribute takes a token from a fixed list, spelt exactly. - Use
type="email"andtype="tel"to get the right phone keyboard. - Save
type="number"for amounts you could count, like cakes.
Easy to get wrong
Without a type and a token, a phone shows the wrong keyboard and the browser has to guess. Both attributes together give the right keyboard and saved values.
A phone number is not an amount. Number fields add spinner arrows, can lose a leading zero, and are announced as a spin button.
Turning autofill off for the whole form makes everyone type every detail by hand, which is hardest for people with motor and memory disabilities.
Only tokens from the HTML standard’s list work. A made-up token is ignored without any warning, so the field gets no help.
Questions people ask
Does autocomplete change what a screen reader says?
Usually not. It helps through the browser’s fill feature and through tools that add icons. The field’s label is still what a screen reader reads.
Does autocomplete share someone’s data with my site?
No. The saved details stay in the browser until the person picks them. The site only receives what ends up in the fields when the form is sent.
Should the postcode field use inputmode="numeric"?
Only where postcodes are digits only, like US ZIP codes. UK and Canadian postcodes contain letters, so a number keyboard would get in the way.
What does WCAG 1.3.5 actually require?
That fields collecting information about the user identify their purpose in code, using the tokens in the HTML standard. In practice that means a correct autocomplete value on each of those fields.