# Form fields that block or break autofill

Source: https://easeweb.dev/learn/autocomplete
Topics: Forms > Fields declare their purpose for autofill (WCAG 1.3.5)
The fix: Give every field that asks for the user's own details the standard autocomplete token for its purpose, such as name, email, postal-code and tel. Remove autocomplete="off" from those fields and from the form, and replace made-up values with tokens from the HTML list.
Test with: autofill, password manager, touch
References: https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html https://www.w3.org/TR/WCAG22/#input-purposes https://www.w3.org/WAI/WCAG22/Techniques/html/H98 https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete

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.

## What happens

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.

## Why it fails

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.

## Who is affected

Typing every detail by hand costs everyone time, and most on a phone, where the keyboard covers half the form.

## What automation and AI miss

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.

## Before: autofill turned off and made-up values

```html
<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>
```

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.

## After: standard autocomplete tokens

```html
<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>
```

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.

## Implementation decisions

**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

1. In the code or the DOM, check every field that asks for the user's own details has an autocomplete token from the HTML list that matches its purpose, and that neither the field nor its form has autocomplete="off".
2. Save your details in two browsers, fill the form with their built-in autofill, and check every value lands in the right field.
3. On a phone and with a password manager, check autofill offers the right detail for each field, and the on-screen keyboard suits the email and phone fields.
4. Check any field that asks about someone else, such as a gift recipient, is not filled with your own details.

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.