# Form fields have correct autocomplete attributes

- **Pattern:** `ab-001756` (`marketing-conversion.form-optimization.autofill-support`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001756
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001756)

## Why it matters

Missing or incorrect `autocomplete` attributes force users to type information their browser or password manager already knows. Password managers rely on both the `name` attribute and `autocomplete` to distinguish `new-password` from `current-password` — without this signal, they may autofill the wrong credential, prefill nothing, or prompt users to save an incorrect entry. WCAG 2.2 SC 1.3.5 (Identify Input Purpose) requires programmatic purpose identification for common personal data fields. Autofill friction is disproportionately punishing on mobile, where typing is slower and error-prone.

## Severity rationale

Low because the failure degrades UX and violates WCAG 2.2 SC 1.3.5 but does not create a direct security or data-loss risk.

## Remediation

Add `autocomplete` and `name` attributes to every personal-data input. Use `new-password` on signup and `current-password` on login — this is the signal password managers use to decide whether to offer to save or fill a credential:

```tsx
<Input
  type="email"
  name="email"
  autoComplete="email"
  placeholder="Work email"
/>
<Input
  type="password"
  name="password"
  autoComplete="new-password"
  placeholder="Create password"
/>
```

Never set `autocomplete="off"` on password fields — it breaks password manager integration across every browser and forces users to type credentials manually on every visit.

## Detection

- **ID:** `autofill-support`
- **Severity:** `low`
- **What to look for:** Examine form input elements in signup, login, and conversion forms. Check whether `autocomplete` attributes are present and use correct values. Standard values: `email` for email fields, `current-password` for login password, `new-password` for signup password, `given-name`/`family-name` for name fields, `organization` for company name, `tel` for phone. Also check that inputs have correct `name` attributes that match field purpose — browsers use both `name` and `autocomplete` to infer autofill intent.
- **Pass criteria:** Count all form fields that should have autocomplete attributes (email, password, name, address). Email fields have `autocomplete="email"`, password fields on signup forms have `autocomplete="new-password"`, password fields on login forms have `autocomplete="current-password"`. At least 80% of applicable fields must have correct autocomplete values. Report: "X of Y applicable fields have correct autocomplete attributes."
- **Fail criteria:** Primary form fields (email and password at minimum) are missing `autocomplete` attributes entirely.
- **Skip (N/A) when:** No forms found, or forms use only a single input field with obvious purpose.
- **Detail on fail:** `"Signup form email input has no autocomplete attribute. Password field uses autocomplete='off' which prevents browser and password manager autofill."`.
- **Remediation:** `autocomplete` attributes let browsers and password managers fill forms for returning users. For a signup form:

  ```tsx
  <Input
    type="email"
    name="email"
    autoComplete="email"
    placeholder="Work email"
  />
  <Input
    type="password"
    name="password"
    autoComplete="new-password"
    placeholder="Create password"
  />
  ```

  Never use `autocomplete="off"` on password fields — this breaks password manager integration and forces users to type passwords manually.

## External references

- wcag 1.3.5

Taxons: user-experience

HTML version: https://auditbuffet.com/patterns/ab-001756