Skip to content
Pandus

WCAG 1.3.5 Identify Input Purpose

Updated October 14, 2026 · 3 min read

Level
AA · WCAG 2.1
EN 301 549
9.1.3.5
What the checker tests
Partly automated: Checkout fields are not filled in automatically
Official text
Understanding 1.3.5 Identify Input Purpose (W3C, in English)

Success criterion 1.3.5 makes forms easier for people with cognitive, memory or motor disabilities. When a field says in code what it is for — "this is the email", "this is the postcode" — browsers can fill it in and assistive tools can show familiar icons or labels. It was added in WCAG 2.1, is level AA and part of EN 301 549 (clause 9.1.3.5).

What the criterion requires

The purpose of each input field collecting information about the user must be programmatically determinable when:

  • the field serves one of the purposes in the WCAG list Input Purposes for User Interface Components (section 7 of WCAG 2.1 and 2.2) — for example name, given-name, family-name, email, tel, street-address, address-line1, postal-code, country, organization, bday, cc-name, cc-number, cc-exp, username, new-password, current-password; and
  • the technology supports it. In HTML it does, through the autocomplete attribute.

It only applies to data about the user. A field for a coupon code, a product search or another person's details is not covered.

Typical failures on an online shop

  • checkout fields for name, email, phone and address with no autocomplete;
  • autocomplete="off" set on the whole checkout form "for security";
  • invalid or wrong values, such as autocomplete="zip" or autocomplete="name" on the email field;
  • separate billing and shipping addresses without the billing and shipping tokens, so the browser fills the wrong one;
  • registration and login fields without username, new-password or current-password.

How to check it

Automated: our checker flags autocomplete values that are not valid or not appropriate for the field (rule autocomplete valid). It cannot tell if a field without autocomplete asks for the user's own data, so missing attributes need a manual check.

By hand: list all forms: registration, login, account, checkout, newsletter, contact. For each field asking for the user's personal data, inspect the code and check the autocomplete value against the WCAG list. Test that the browser's autofill fills the right fields.

How to fix it

  • Add the correct token to each field, for example <input type="email" autocomplete="email">.
  • Use section tokens for addresses: autocomplete="shipping postal-code" and autocomplete="billing postal-code".
  • Remove autocomplete="off" from personal data fields.
  • On Shopify, WooCommerce and other platforms, check theme and plugin overrides of the checkout and account forms; the platform defaults may already set them.

Frequently asked questions

Which fields need an autocomplete attribute?

Fields that collect information about the user themselves and match one of the input purposes listed in WCAG, for example name, email, tel, street-address, postal-code, country, cc-number or new-password.

Does 1.3.5 apply to a gift recipient address?

The criterion is scoped to information about the user. Fields about another person are not required to expose their purpose, although adding the shipping tokens can still help.

Is autocomplete="off" a failure?

On a field that collects the user's own data listed in WCAG, yes: the purpose must be programmatically determinable, and "off" does not identify it.

What does the automated check find?

Our checker flags autocomplete values that are invalid or do not fit the field. It cannot know whether a field without autocomplete asks for the user's own data, so missing attributes need a manual look.