WCAG 1.3.5 Identify Input Purpose requires that the purpose of each form field collecting information about the user — their name, email, phone, or address — can be programmatically determined. In practice, on the web that means adding the correct HTML autocomplete token to those fields so browsers and assistive tech understand them.

What WCAG 1.3.5 means in plain English

This is a Level AA criterion added in WCAG 2.1. The normative wording asks that the purpose of an input “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” (W3C Understanding 1.3.5).

Translated: machines should be able to tell that this box is for an email address and that box is for a postal code — not by guessing from the visible label, but from a fixed, recognized code in the markup. HTML already has that code. The autocomplete attribute accepts a closed list of standardized field-name tokens (name, given-name, email, tel, street-address, postal-code, cc-number, and so on) defined in the WCAG Input Purposes list — 53 HTML autofill tokens in all, per DigitalA11Y’s enumeration of the spec. Put the right token on the right field and you meet the criterion.

A critical scope limit: 1.3.5 only covers inputs asking for information about the user filling out the form. It does not apply to a field asking for a friend’s name, a search query, a quantity, or any non-text input. That narrow scope is exactly why this is one of the most mechanical, low-risk fixes in all of WCAG.

Who it helps, and why

The W3C is explicit that 1.3.5 was written primarily for people with cognitive, language, and memory-related disabilities (W3C Understanding 1.3.5). When a field is tagged autocomplete="bday", the browser can offer the user’s stored birthday so they confirm instead of recall and re-type it. For someone with dyslexia, a head injury, or memory loss, that difference between recognize and recall is the difference between finishing your checkout and abandoning it.

It also helps people with motor and dexterity impairments — cerebral palsy, stroke, tremor — by cutting the amount of typing required. And it enables a class of assistive technology that swaps in familiar icons: a tool can render a telephone icon beside autocomplete="tel" or a birthday-cake icon beside autocomplete="bday", giving non-readers a visual anchor for each field. None of that can happen unless the purpose is in the code.

Concrete failure examples and the fix

The official failure for this criterion is F107: incorrect autocomplete attribute value. There are three common ways forms trip it.

1. The token is missing entirely. A standard sign-up form with bare inputs:

<label for="fname">First name</label>
<input id="fname" type="text">
<label for="email">Email</label>
<input id="email" type="email">

These collect user info but expose no purpose. The fix is the documented sufficient technique, H98:

<label for="fname">First name</label>
<input id="fname" type="text" autocomplete="given-name">
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

2. The token is invented or misspelled. This is the classic F107 trap:

<!-- "birthday" is not a real token -->
<input id="dob" type="text" autocomplete="birthday">

The valid token is bday. Browsers silently ignore the bad value, so it looks fine and still fails. Use the exact spelling from the spec.

3. The token is valid but wrong for the field. A name field carrying autocomplete="email" is technically a real token in the wrong place — it fails because the programmatic purpose no longer matches the actual purpose. The token must describe what the field genuinely collects.

For multi-part data, use the granular tokens: address-line1, address-level2 (city), address-level1 (state/region), postal-code, and country-name. For payment, cc-name, cc-number, cc-exp. These are documented in our accessible forms guide alongside the labeling work that pairs with them.

How to test for 1.3.5

There is no contrast-style number to measure here — testing is a structured review of your user-data fields.

  1. List every field that asks for the user’s own information. Name, username, email, phone, address blocks, date of birth, payment details. Ignore search boxes, quantities, and third-party fields — they are out of scope.
  2. Inspect the markup. Open DevTools and confirm each in-scope field has an autocomplete attribute. Empty or absent equals a fail.
  3. Validate the token spelling. Cross-check every value against the HTML autocomplete tokens in H98. A single typo (firstname instead of given-name, phone instead of tel) is an F107 failure.
  4. Confirm token-to-field alignment. Read the visible label or instruction and make sure the token actually describes that field’s purpose.
  5. Try it live. Save a profile in your browser, then load the form. Fields with correct tokens should offer autofill; the ones that stay blank are usually the ones missing or misusing the attribute.

Automated scanners flag missing or non-standard autocomplete values quickly, but they cannot judge whether a valid token is on the right field — that final alignment check is human work, which is why thorough conformance always pairs tooling with hands-on review. A free Curbcut scan is a fast way to surface the missing-token cases first.

For a tiny attribute, 1.3.5 carries real weight — and the weight is concentrated exactly where this criterion lives: the checkout and registration forms of online stores. It is part of WCAG 2.1 Level AA, the conformance target U.S. courts and the Department of Justice treat as the practical benchmark for an accessible website under the ADA (ADA.gov guidance on web accessibility). UsableNet’s year-end tracker counted 4,187 digital accessibility lawsuits in 2024, and 77% of them targeted e-commerce sites — the very properties whose name, email, address, and payment fields fall squarely under 1.3.5 (UsableNet, 2024 Year-End Report). When a plaintiff’s expert walks a checkout or sign-up flow, a name field with no autocomplete="given-name" or a card field missing autocomplete="cc-number" is a fast, screenshot-ready AA finding that lands in demand letters right next to heavier issues — because, unlike interpretive criteria, a missing or invalid token is either there in the markup or it isn’t.

The encouraging news: this is among the cheapest criteria to remediate. There is no redesign, no copy change, and no visual impact — you are adding a handful of standardized tokens. The work is in being precise and exhaustive across every form, every step, every state.

This page is general information, not legal advice. For your specific exposure, consult a qualified attorney such as [EXPERT_NAME] at [AGENCY_NAME].

How Curbcut fixes 1.3.5

We add and verify autocomplete tokens directly in your code, field by field, and confirm each one matches its real purpose and visible label. That is deliberate manual remediation — not an overlay widget. An overlay can’t reliably guess the purpose of your fields or inject correct tokens, and it won’t satisfy a skeptical reviewer or a VPAT. We fix the markup so the default form is conformant, then document it.

1.3.5 is one checkpoint among dozens in a full accessibility audit. It’s a quick win that pairs naturally with labels, error handling, and keyboard support across your forms. If you’d rather not inspect every field by hand, start with a free scan and we’ll show you exactly which inputs are missing their purpose — then remediate them for you.