1.3.5 Identify Input Purpose

WCAG 2.2 · 1.3.5 AA Perceivable

What it requires

When an input field collects information about the user, the purpose of that field must be programmatically determinable — provided the field maps to one of the input-purpose values listed in the WCAG specification (for example name, email, telephone, street address, postal code, country, or credit-card fields). In practice this is met by adding the correct HTML autocomplete token to each relevant field, so that browsers, password managers, and assistive technologies can recognise and adapt it.

The criterion applies only to fields about the person filling in the form — not to arbitrary inputs such as a search box, a quantity, or a message body.

  • People with cognitive and memory disabilities — auto-fill and recognisable fields reduce the effort and recall needed to complete forms.
  • People with motor disabilities — fewer keystrokes when fields are populated automatically.
  • People who benefit from symbols or personalised presentation — tools can add familiar icons next to known field types (e.g. a phone icon by a tel field).
  • Screen-reader and AT users — a clear, machine-readable purpose improves how fields are announced and handled.

How to detect it

Checks for Identify Input Purpose
Method What to look for
Manual / code review Inspect each input that collects user data. Confirm it has an autocomplete attribute with the correct token from the WCAG list.
Browser auto-fill Trigger the browser's saved auto-fill; correctly tagged fields should populate with the right data type.
Automated tools Tools like axe can flag invalid or mistyped autocomplete values, but cannot reliably tell whether a field should have one — manual review is still required.
Token validity Watch for typos (e.g. e-mail instead of email) and misused tokens, which silently fail the criterion.

How to fix it

  1. Identify every field that collects information about the user.
  2. Match each to its WCAG/HTML input-purpose token (e.g. name, email, tel, postal-code).
  3. Add the autocomplete attribute with that exact token.
  4. Keep visible labels and type attributes correct too — they reinforce the purpose for users and AT.
  5. Re-test with browser auto-fill and an automated check to confirm valid tokens.
<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email">

<label for="tel">Phone</label>
<input id="tel" name="tel" type="tel" autocomplete="tel">

Copy-paste tests

Automated coverage

The axe-core rule autocomplete-valid flags failures of this criterion. Run it via the axe DevTools browser extension or axe-core in CI. Automated tools only catch SOME failures — they cannot tell whether a personal-data field is missing an autocomplete token entirely.

Run this in the browser console

console — find-input-purpose.js 
// Read-only: lists inputs likely to need an autocomplete token.
const hint = /name|email|e-?mail|phone|tel|mobile|address|street|city|zip|postal|country|card|cc-|birth|dob/i;
const suspects = [...document.querySelectorAll('input, select, textarea')]
  .filter(el => !el.autocomplete && hint.test([el.name, el.id, el.placeholder].join(' ')));
console.table(suspects.map(el => ({
  tag: el.tagName, type: el.type, name: el.name, id: el.id,
  autocomplete: el.autocomplete || '(none)'
})));
suspects.forEach(el => el.style.outline = '2px solid red'); // visual only

What to check manually: for each highlighted field, decide whether it collects information about the user and, if so, that any existing autocomplete token is the correct WCAG value rather than a plausible-but-wrong one.