1.3.5 Identify Input Purpose: what it requires and how to test it

What 1.3.5 requires

The purpose of each input collecting information about the user must be programmatically determinable, when the field matches one of WCAG's listed Input Purposes and the technology supports it. On the web, that means setting the right autocomplete token (name, email, tel, street-address, postal-code, cc-number and so on) so browsers can autofill and assistive tools can recognise or add icons to fields. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 1.3.5 (opens in a new tab) [1][2].

Exceptions and scope:

• Only information about the user. The Understanding document says a field for information that isn't about the user (a gift recipient's address, for example) doesn't need to expose its purpose, even if the purpose is on the list.
• Only listed purposes. The criterion covers WCAG's Input Purposes list, which borrows from the HTML autofill definitions. Fields outside that list aren't in scope.

Why it matters

Typing is slow and error-prone for many people: those with motor impairments, people using switch devices or on-screen keyboards, and people with cognitive or memory disabilities who may not recall a postcode or card number. Correct autocomplete lets the browser fill the field in one step. Our checkout guide describes the cost of getting it wrong: retyping a full address on a small screen, or with a switch device.

Common failures

Personal fields with no autocomplete

Autofill guesses or does nothing.

<!-- Fails -->
<label for="e">Email</label> <input id="e" type="email">

<!-- Better -->
<label for="e">Email</label> <input id="e" type="email" autocomplete="email">

Autocomplete turned off on the user's own details

<!-- Fails -->
<input id="name" autocomplete="off">

<!-- Better -->
<input id="name" autocomplete="name">

Wrong or invented token

An invalid token is ignored by browsers.

<!-- Fails -->
<input id="zip" autocomplete="zip">

<!-- Better -->
<input id="zip" autocomplete="postal-code">

Split fields without the matching tokens

First and last name, or card expiry month and year, need their specific tokens.

<!-- Fails -->
<input id="fn" autocomplete="name"> <input id="ln" autocomplete="name">

<!-- Better -->
<input id="fn" autocomplete="given-name"> <input id="ln" autocomplete="family-name">

Can automated testing check 1.3.5?

Partly. axe-core can check that an autocomplete value is valid and suits the field. It can't tell that a field without one should have had it.

What automation can't decide: Whether a field collects information about the user (and so needs a token), whether a missing autocomplete is a failure, and whether the chosen token matches what the label actually asks for.

A clean automated result is never proof that 1.3.5 is met. See why sites pass axe-core but fail real screen reader users.

How to test it by hand

1. List every field on your sign-up, account, contact and checkout forms.
2. Mark which ones ask for the user's own information and match a purpose on WCAG's Input Purposes list.
3. Check each of those has the right autocomplete token, including the specific ones for split fields.
4. Try autofill in two browsers with a saved profile. Does every field fill correctly?
5. Check no field the user needs to autofill has autocomplete="off".

New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.

How Accessible helps (and where it stops)

Scanning runs autocomplete-valid on every URL on a paid plan. The assistant tools' form-fields check goes one step further on a single page: it lists missing autocomplete on personal data among the barriers for each field (assistants). Our checkout accessibility page lists 1.3.5 among the criteria a checkout journey covers.

Where it stops: Deciding which fields are about the user, and which token is right, still takes a person reading the form. Autofill behaviour also varies by browser, so try it. No automated tool, ours included, can certify that a criterion is met.

Related criteria

• 3.3.2 Labels or Instructions
• 1.3.1 Info and Relationships
• 4.1.2 Name, Role, Value
• WCAG 2.2 success criteria checklist

Sources

1. Understanding Success Criterion 1.3.5: Identify Input Purpose (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
2. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.3.5 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
3. axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
4. HTML Living Standard: Autofill (opens in a new tab). WHATWG. Accessed October 18, 2026.

Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.