WCAG 1.3.5 — Identify Input Purpose

What this requires

Input fields that collect information about the user have to identify their purpose with the appropriate HTML autocomplete token. The full list lives in the HTML specification — name, email, tel, street-address, postal-code, cc-number, bday, and dozens more. Setting the token enables browser autofill, password-manager integration, and the cognitive-accessibility features that swap fields for symbol-based equivalents.

How AI coding tools fail this

The default failure: AI assistants scaffolding a form set name="" and id="" correctly, then never touch autocomplete. The form submits, but autofill misses, password managers don't recognise the credential fields, and cognitive-accessibility tools cannot identify what each input is for.

The second pattern: autocomplete="off" applied to entire forms as a "privacy" or "security" gesture. Modern browsers ignore the attribute on password fields anyway, but on the rest of the form it disables autofill, which actively hurts users with motor disabilities (who benefit from autofill the most).

The third: invented tokens. autocomplete="user-email" or autocomplete="phone" look plausible but are not in the spec. Browsers ignore them silently.

Failing examples

A login form with no autocomplete metadata:

<input type="email" name="email" />
<input type="password" name="password" />

autocomplete="off" applied across the board:

<form autoComplete="off">
  <input type="text" name="given_name" />
  <input type="text" name="family_name" />
</form>

Passing examples

Use the standardised tokens for each purpose:

<input type="email" name="email" autoComplete="email" />
<input type="password" name="password" autoComplete="current-password" />

A name form with the right purpose tokens:

<input type="text" name="given_name" autoComplete="given-name" />
<input type="text" name="family_name" autoComplete="family-name" />

Edge cases

New passwords use autocomplete="new-password", not current-password. The browser uses this signal to offer to generate and save a strong password.
Multi-step forms can split a single purpose across multiple fields (e.g. cc-number-1, cc-number-2). The HTML spec covers these cases; consult before inventing.
Address forms localise differently. Use address-line1, address-line2, postal-code, country rather than country-specific names like zip.
One-time codes (SMS verification) use autocomplete="one-time-code" to receive automatic fill from the OS.
Sensitive data doesn't justify disabling autocomplete. If you must opt out for one field, use autocomplete="off" on that field alone, not the form.

How Jeikin handles this

Jeikin's MCP server provides the canonical autocomplete token list to the connected AI tool when it generates a form. The dashboard tracks findings for inputs that match a known purpose (email, password, name, address) but lack the corresponding autocomplete attribute.