WCAG 1.3.5: Identify Input Purpose
Your label tells a human what a field wants; this criterion makes the field tell software. Fields that collect information about the user must expose their purpose programmatically — which on the web means the HTML autocomplete attribute. One token per field, and browsers can autofill, password managers can help, and assistive tools can show familiar icons instead of unfamiliar words.
The success criterion, in full
The purpose of each input field collecting information about the user can be programmatically determined when: the input field serves a purpose identified in the Input Purposes for User Interface Components section; and the content is implemented using technologies with support for identifying the expected meaning for form input data.
Both conditions gate the requirement. The field must (a) collect information about the user and (b) match one of the 53 input purposesWCAG enumerates — the same vocabulary as HTML’s autofill tokens. HTML supports identifying input meaning via autocomplete, so for HTML forms the criterion is squarely in effect.
Who this helps
People with memory and cognitive disabilities
Recalling and typing an address, a phone number, or a card number is a genuine barrier. With correct tokens the browser fills it once and forever — the form stops depending on recall.
People with language impairments or aphasia
Personalization tools can read the token and add a familiar icon — a phone symbol, an envelope, a house — beside each field. Symbols the user already knows replace labels they may struggle to decode.
People with motor disabilities
Every autofilled field is dozens of keystrokes or switch activations saved. For someone typing with a head pointer or an on-screen keyboard, autofill turns a ten-minute form into seconds.
Everyone on a phone at checkout
Correct tokens are also just good commerce: browsers fill entire address and payment forms in one tap, cutting errors and abandonment. The accessible markup and the conversion optimization are the same attribute.
Scope: which fields and which purposes
A field is in scope only when it collects information about the user filling in the form andits purpose appears in WCAG’s fixed list of 53 input purposes. The most common tokens by group:
Identity
name, given-name, family-name, honorific-prefix, nickname, username, new-password, current-password, bday, sex, organization, organization-title, photo, language
Contact
email, tel (plus tel-national, tel-local and other parts), url, impp
Address
street-address, address-line1/2/3, address-level1 (state), address-level2 (city), postal-code, country, country-name
Payment & transaction
cc-name, cc-number, cc-exp, cc-exp-month, cc-exp-year, cc-csc, cc-type, transaction-currency, transaction-amount
Out of scope, and therefore requiring no token: fields about other people(a gift recipient’s address, an emergency contact), and fields whose purpose is not on the list (search queries, comments, quantities, coupon codes). The list is closed — you cannot invent tokens, and you should not force a wrong token onto an unlisted field.
Tokens compose with modifiers: shipping / billing prefixes distinguish address groups, and section-* names separate repeated blocks (e.g. two travelers on one booking). This layer is about machine-readable purpose — the human-readable label is still governed by 3.3.2 Labels or Instructions and 2.4.6 Headings and Labels.
Pass and fail examples
- Pass — Checkout with full autocomplete tokens. Name, email, phone, address, and card fields each carry the matching token (name, email, tel, street-address, postal-code, cc-number, cc-exp). The browser offers to fill everything, and tools can identify every field's meaning.
- Pass — Shipping vs billing distinguished with modifiers. The form uses autocomplete="shipping street-address" and autocomplete="billing street-address", so both the purpose and which address it is are programmatically clear.
- Pass — Search box without a token. A site search field has no autocomplete token. A search query is not information about the user and is not among the 53 listed purposes, so 1.3.5 simply does not apply to it.
- Fail — Registration form with no tokens. A sign-up form asks for the user's name, email, and phone using plain <input type="text"> fields with no autocomplete attributes. All three purposes are on the list; none is programmatically determined.
- Fail — autocomplete="off" on the user's own data. An account-profile form sets autocomplete="off" on the user's address and birth date 'to keep data clean'. The purposes are listed and about the user, so suppressing them fails the criterion.
Code examples
A registration form, before and after
The type attribute and a good label are not enough — the autocomplete token is what makes the purpose programmatic.
<!-- ✗ Failing: purposes on the list, none programmatically identified -->
<label for="n">Full name</label>
<input id="n" type="text" />
<label for="e">Email</label>
<input id="e" type="email" autocomplete="off" />
<label for="p">Phone</label>
<input id="p" type="text" />
<!-- ✓ Passing: one correct token per field -->
<label for="name">Full name</label>
<input id="name" type="text" autocomplete="name" />
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email" />
<label for="tel">Phone</label>
<input id="tel" type="tel" autocomplete="tel" />
<label for="bday">Date of birth</label>
<input id="bday" type="date" autocomplete="bday" />Shipping, billing, and payment at checkout
Modifier prefixes tell software which address each field belongs to; the cc-* family covers the payment card.
<fieldset>
<legend>Shipping address</legend>
<input autocomplete="shipping street-address" ... />
<input autocomplete="shipping address-level2" ... /> <!-- city -->
<input autocomplete="shipping postal-code" ... />
<select autocomplete="shipping country">…</select>
</fieldset>
<fieldset>
<legend>Billing address</legend>
<input autocomplete="billing street-address" ... />
<input autocomplete="billing postal-code" ... />
</fieldset>
<fieldset>
<legend>Payment</legend>
<input autocomplete="cc-name" ... />
<input autocomplete="cc-number" inputmode="numeric" ... />
<input autocomplete="cc-exp" placeholder="MM/YY" ... />
<input autocomplete="cc-csc" inputmode="numeric" ... />
</fieldset>Repeated groups with section-*
When one form collects the same user-related purposes more than once, name each block so autofill does not smear one person’s data across both.
<h2>Your details</h2>
<input autocomplete="section-primary name" ... />
<input autocomplete="section-primary email" ... />
<h2>Frequent flyer account holder (you, on a second program)</h2>
<input autocomplete="section-loyalty name" ... />
<input autocomplete="section-loyalty email" ... />
<!-- Note: a field about someone ELSE (gift recipient, emergency
contact) is out of scope for 1.3.5 — no token is required. -->Common failures
- No autocomplete attributes at all on registration, checkout, or profile forms that collect the user's own listed data.
- autocomplete="off" on in-scope fields 'for security' or 'data quality' — it removes the programmatic purpose and the autofill help.
- Wrong tokens: autocomplete="name" on an email field, or made-up values like autocomplete="phone" (the token is tel) that browsers ignore.
- Relying on type="email" or type="tel" alone — input types hint at format, but the WCAG-listed purpose is conveyed by the autocomplete token.
- Custom JavaScript form controls that render as <div>s with no underlying input capable of carrying an autocomplete attribute.
- Shipping and billing addresses with identical bare tokens, so software cannot tell which street-address is which (use the shipping/billing modifiers).
- Breaking autofill with per-field masking scripts that clear or reformat programmatically filled values, defeating the purpose the token declared.
How to test for 1.3.5
- 1
List every field that asks about the user
Walk each form and mark the fields collecting the user's own information. For each, check WCAG's input-purposes list (it mirrors the HTML autofill tokens). On the list → in scope; about someone else or unlisted → out of scope.
- 2
Inspect the markup for correct tokens
In DevTools, verify each in-scope field carries the correct autocomplete token — not a misspelling, not a near-miss (phone vs tel), not autocomplete="off". Check that modifiers (shipping/billing, section-*) are used where groups repeat.
- 3
Run automated checks
axe DevTools and Lighthouse include an autocomplete-valid rule that flags malformed or inappropriate tokens. Automated tools catch invalid values well; they cannot decide scope (is this field about the user?), so keep step 1 human.
- 4
Test real autofill behavior
With a browser profile that has a saved address and card, open the form and trigger autofill. Every in-scope field should be offered the right data, and the filled values should survive your validation and masking scripts.
- 5
Confirm labels are still doing their own job
Tokens don't label. Tab through with a screen reader and confirm each field still announces a descriptive name — 1.3.5 works alongside 3.3.2 and 2.4.6, not instead of them.
This is one of the most mechanical AA criteria to fix — usually one attribute per field. Sweep your forms, then continue through the WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 1.3.5 Identify Input Purpose require?
It requires that the purpose of each input field collecting information about the user can be programmatically determined — but only when two conditions hold: the field serves a purpose identified in WCAG's 'Input Purposes for User Interface Components' list (53 purposes such as name, email, tel, street-address, bday, cc-number), and the technology supports identifying the expected meaning of form input (in HTML, the autocomplete attribute does exactly this). In practice: put the correct autocomplete token on every field that asks for the user's own listed information. Introduced in WCAG 2.1 at Level AA, unchanged in 2.2.
Which fields are in scope for 1.3.5?
Only fields collecting information about the user filling in the form, and only when the data type appears in WCAG's fixed list of 53 input purposes. Your email, your name, your phone, your shipping address, your card number: in scope. A field asking for someone else's details — a gift recipient's address, an emergency contact's phone — is not information about the user, so it is out of scope. Likewise fields whose purpose is not on the list at all (a search query, a product review, a coupon code) are out of scope, no matter who they concern.
Why does 1.3.5 matter — isn't a visible label enough?
Labels serve people who can read and interpret them. 1.3.5 serves people for whom machine-readable purpose unlocks help: browsers autofill the field so users with memory or dexterity limitations don't have to recall and retype their address or card number, password managers and assistive tools can act on the field's meaning, and specialized tools can render familiar icons next to fields (a phone symbol on every telephone field) for people with cognitive disabilities or aphasia who recognize symbols more easily than words. The visible label is for humans; the token is for software helping humans.
Does autocomplete="off" fail 1.3.5?
On an in-scope field, yes — autocomplete="off" (or a missing/incorrect token) means the field's purpose is not programmatically determined, and it also suppresses the autofill that users with cognitive and motor disabilities rely on. Teams often disable autofill on login or payment forms citing security, but browsers largely ignore autocomplete="off" for saved credentials anyway, and WCAG provides no security exception. If a field asks for the user's own listed data, give it the correct token.
What's the difference between 1.3.5 and 1.3.6 Identify Purpose?
1.3.5 (Level AA) covers input fields collecting user information and is satisfied with autocomplete tokens. 1.3.6 Identify Purpose (Level AAA, also new in 2.1) is much broader: in content implemented with markup, the purpose of user interface components, icons, and regions must be programmatically determinable — enabling personalization tools to swap symbols and hide non-essential content across the whole page. AA conformance requires only 1.3.5.
Do autocomplete tokens affect the accessible name or how screen readers announce a field?
No — the token identifies purpose to software; it does not label the field. The accessible name still comes from the <label>, aria-label, or equivalent (covered by 3.3.2, 2.4.6, and 4.1.2). A field can pass 1.3.5 with a perfect token and still fail labeling criteria, or vice versa. Treat them as separate layers: human-readable label, machine-readable purpose — in-scope fields need both.
Related Success Criteria
Information, structure, and relationships can be programmatically determined.
Content can be presented in a meaningful sequence without losing meaning.
Instructions don't rely solely on sensory characteristics of components.
Content does not restrict its view to a single display orientation.
The purpose of User Interface Components can be programmatically determined.