1.3.5 Identify Input Purpose

This criterion exists so that software can help people fill in forms about themselves. When a field declares in machine-readable form that it collects the user's email address, name, or phone number, browsers and assistive tools can autofill it, and specialised tools can decorate it with familiar icons or plain-language prompts. That matters most for people with cognitive and memory disabilities, who may struggle to recall or transcribe their own details, and for people with motor impairments, for whom every keystroke saved is a real reduction in effort and error.

The auditor's mental model has two filters. First, the field must collect information about the user: their own name, email, address, phone, birthday, payment details. A field asking for someone else's details is out of scope. Second, the purpose must be one of the entries in WCAG's fixed Input Purposes list; anything not on that list (a search query, a message body, a company reference number) is out of scope regardless of who it describes. Fields that survive both filters must expose their purpose programmatically, which on the web means a correct autocomplete token. A wrong token is worse than none: it actively asserts a false purpose that software will act on.

Passes:

• A registration form where the name fields carry autocomplete="given-name" and autocomplete="family-name", the email field autocomplete="email", and the phone field autocomplete="tel".
• A checkout billing form using composed tokens such as autocomplete="billing street-address" and autocomplete="billing postal-code": the modifiers are valid and the purpose tokens are correct.
• An iOS sign-in screen whose username field sets .textContentType(.username) and whose email field sets .textContentType(.emailAddress).
• An Android profile screen whose phone field declares android:autofillHints="phone" and offers the user's stored number when focused.
• A search box with no autocomplete attribute: a search query is not on the Input Purposes list, so the criterion does not apply to it.

Fails:

• An account signup email field with no autocomplete attribute: the field collects the user's email, a listed purpose, and declares nothing.
• A phone number field marked autocomplete="email": a wrong token is graded as a failure even though a token is present, because it programmatically asserts a false purpose.
• A profile form with autocomplete="off" across the user's name and address fields: suppressing autofill also removes the programmatic purpose from in-scope fields.
• A date-of-birth field using an invented token like autocomplete="date-of-birth" instead of bday: values outside the specification identify no purpose.
• An Android account settings screen rebuilt with custom Compose text fields that set no content type semantics on the user's email and postal code fields.

Not a fail under this criterion:

• A gift delivery form asking for the recipient's name and address when the recipient is not the user: the criterion only covers information about the user themselves.
• A message body, order note, or company VAT number field with no token: those purposes are not on the Input Purposes list.
• A field whose visible label is missing or unclear: visible identification for humans is graded under SC 3.3.2 Labels or Instructions, not here.
• A site that re-asks for details the user already entered earlier in the same process: that is Redundant Entry, whether or not the fields carry correct tokens.

• Redundant Entry, SC 3.3.7. Marking a field's purpose does not excuse asking for the same information twice. The two are graded independently, and platform autofill does not satisfy 3.3.7: even where correct tokens let the browser refill a repeated field, the content itself must auto-populate or offer the previous answer for selection, so re-asking is still a 3.3.7 fail.
• Labels or Instructions, SC 3.3.2. That criterion is about what a human can see: a visible label or instruction identifying the field. 1.3.5 is about what a machine can read. A field can have a perfect visible label and no token (fails here, passes 3.3.2), or a correct token and no visible label (passes here, fails 3.3.2).
• Accessible Authentication (Minimum), SC 3.3.8. Login screens that block paste or fight password managers create a memorisation and transcription burden, and that finding lands under 3.3.8. File the cognitive-burden finding there; 1.3.5 covers whether identity fields declare their purpose.
• Info and Relationships, SC 1.3.1. Programmatically associating a visible label with its field (a for/id pairing, for instance) is a 1.3.1 structure finding. 1.3.5 asks a different question: whether the field's purpose is declared from the fixed list. A field can be perfectly labelled and associated yet still fail 1.3.5.

AUDITSU's audit walkthrough covers this criterion on every screen that collects personal details. For each form screen you review, the walkthrough asks you to identify the fields that collect information about the user themselves, filter them against the Input Purposes list, and then inspect the declared purpose: autocomplete tokens on web, textContentType on iOS, autofill hints or Compose content type semantics on Android. Each check records a pass, fail, or not applicable result per screen with the evidence attached, so a wrong token on a checkout field lands in your report tied to the exact screen and control.

For audits against the European standard, the walkthrough applies the criterion to web content and to software that supports assistive technologies. On closed systems, where assistive technologies cannot be attached, the requirement changes shape entirely: input purposes must be presented in audio form, and the walkthrough prompts for that instead.

For the full guided workflow, see the audit platform.