How to fix: Common inputs missing autocomplete

The autocomplete attribute names the purpose of a form field using a fixed vocabulary of tokens defined in the HTML spec, such as name, given-name, family-name, email, tel, street-address, address-level2 (city), address-level1 (state/region), postal-code, and country-name. WCAG Success Criterion 1.3.5 Identify Input Purpose requires that when a field collects information about the user, its purpose be programmatically determinable, and these tokens are how you declare it.

Two things use that declared purpose. Browsers and password managers use it to autofill the field accurately, so the user does not retype their email or address on every site. And assistive technology, including tools that swap in familiar icons or simplified language for a field, uses it to present the input in a way the user already understands. A field whose purpose is only implied by a visible label or a placeholder is not programmatically identified.

Adding the attribute does not change how the field looks or behaves for people who type manually; it simply attaches a machine-readable purpose. Note this is separate from labeling: a field can have a perfectly good <label> and still fail SC 1.3.5 because the label tells humans what to type while autocomplete tells software what the field is for.

People with motor disabilities and anyone who finds typing slow, painful, or error-prone benefit most, because correct autocomplete lets the browser or password manager fill the field instead of forcing manual entry on every form. It also helps people with cognitive disabilities and memory limitations who struggle to recall details like a full postal address.

Users of assistive tools that re-present fields with familiar symbols or plain language rely on the declared purpose to do that substitution, and even users without disabilities get faster, lower-friction checkouts and sign-ups, which reduces form abandonment for everyone.

Missing autocomplete on personal-data fields is a Level AA failure under SC 1.3.5, and Level AA is the conformance tier courts and the U.S. Department of Justice point to when applying the ADA to websites. Because the criterion is automatically testable, it is the kind of issue an auditor or a plaintiff's tool can document at scale across your forms.

It is also low-risk, high-leverage to fix: you are adding one attribute per field on the forms where conversions happen, so closing the gap improves real-world completion rates while clearing a documented Level AA item from any audit or demand letter. With accessibility lawsuits climbing year over year and most targeting businesses under $25 million in revenue, removing automatically-detectable failures is an easy win.

1. List the text-like inputs on each form (you can ignore hidden, submit, button, checkbox, and radio inputs).
2. Identify which fields collect the user's own data: name, first or last name, email, phone, address, city, state, ZIP, country.
3. Add the matching token from the HTML autocomplete vocabulary, for example email to email, phone to tel, ZIP to postal-code, city to address-level2, and state to address-level1.
4. Use the standard token spelling exactly; a guessed or misspelled value will not be recognized by browsers or assistive tech.
5. Keep the field's real <label> as well, because labeling and identifying input purpose are separate requirements.
6. Re-scan and test that your browser now offers to autofill the fields you tagged.

<label for="email">Email</label>
<input type="email" id="email" name="email">

<label for="zip">ZIP code</label>
<input type="text" id="zip" name="zip">

<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email">

<label for="zip">ZIP code</label>
<input type="text" id="zip" name="zip" autocomplete="postal-code">

AccessKnight selects text-like inputs, excluding hidden, submit, button, checkbox, and radio types, and skips any input that already has an autocomplete attribute. For the rest, it combines the field's name, id, and placeholder into one lowercase string (stripping underscores, hyphens, and brackets) and checks it against a dictionary of known personal-data hints, name, first/last name, email, phone/telephone, address, city, state, zip/zipcode, and country. When a hint matches, it flags the field and recommends the matching token, for example email maps to email, phone maps to tel, zip maps to postal-code, city maps to address-level2, and state maps to address-level1.