WCAG 1.3.5 Identify Input Purpose

What it asks

WCAG keeps a list of input purposes: the common pieces of information about the person filling in a form. Name, given name, family name, email, telephone, street address, postcode, country, date of birth, credit card number and about fifty others. This rule says that when a field collects one of those, its purpose must be programmatically determinable.

In HTML, that means the autocomplete attribute with the matching token: autocomplete="email", autocomplete="given-name", autocomplete="postal-code", autocomplete="tel". The browser then knows what the field is for and can fill it from what it has stored. Assistive tools can use the same information to show a familiar icon or label in place of whatever the site called the field.

The rule applies only to fields about the person using the form, not about someone else. A delivery address for a gift recipient, or a search box, is not covered. It applies only to purposes on the list; a field for a favourite colour has no token and needs none.

Two things fail. A token that is not on the list, such as autocomplete="user-name" or autocomplete="postcode", tells the browser nothing. And no token at all on a field that clearly collects a listed purpose. The second is by far the more common, because most forms simply never add the attribute, and autocomplete="off" added to stop browsers filling fields takes the information away again.

Its official name is success criterion 1.3.5 Identify Input Purpose, at Level AA. It was added in WCAG 2.2, under guideline 1.3 Adaptable and the principle Perceivable. The W3C’s normative text says, in part:

“The purpose of each input field collecting information about the user can be programmatically determined when:”

From WCAG 2.2, W3C. Full explanation: Understanding 1.3.5 Identify Input Purpose.

Who it helps

People with cognitive disabilities, memory difficulties and dyslexia, for whom typing an address or an email correctly is hard and for whom the browser filling it in removes the task. People with motor disabilities, for whom every field typed is effort.

It also lets assistive tools replace a site’s own labels with familiar ones, so a field the site calls "E-mail address" and another calls "Your email" can both show the same icon and name to someone who relies on consistency.

What passes and what fails

These pass

• An email field with autocomplete="email".
• A name split into two fields with autocomplete="given-name" and autocomplete="family-name".
• An address form with street-address, address-level2, postal-code and country tokens on the matching fields.
• A phone field with autocomplete="tel".
• A field asking for someone else’s details, such as a recipient’s name, with no token. It is not about the user.

These fail

• A sign-up form with name, email and phone fields and no autocomplete attributes anywhere.
• autocomplete="off" on name and email fields, added to stop the browser filling them.
• Invented tokens such as autocomplete="user-name", autocomplete="postcode" or autocomplete="phone".
• A valid token on the wrong field, such as autocomplete="email" on a username field that is not an email address.
• A checkout address form that declares the postcode and nothing else.

How to test it by hand

1. Find every form on the page that asks for details about the person filling it in: sign-up, sign-in, checkout, contact, profile and application forms.
2. For each field, decide whether its purpose is on WCAG’s list of input purposes. Name, email, phone, address, date of birth and payment details usually are.
3. In the code, read the field’s autocomplete attribute. Check that it is present and that its token is on the list and matches the field.
4. Try filling the form with the browser’s autofill. Fields the browser fills correctly are declaring their purpose; fields it skips or fills wrongly are not.
5. Note each listed field with no token, an invalid token or the wrong token.

What automated testing can decide

What a machine can decide

Whether a token is valid is a lookup. Automated testing can read every autocomplete attribute, check it against the list, and report an invented one as a clear failure. It can also find the forms and the fields and read their labels, which is the evidence needed to decide what each field is for.

What it cannot

The real-world failure is the missing token, and finding it means deciding what a field with no token is for. "Your email" is easy; "Contact" or "Where should we send it?" is not. Whether a field is about the user or about someone else is a question of context. Automated testing can suggest an answer from the label, the placeholder and the surrounding text; it cannot settle it.

How Dreven handles it

Dreven finds the form fields on your pages that ask for details about the person filling them in and shows you each one, with its label, the page and what the field tells a browser about its purpose.

A reviewer decides each result, and the report says how each one was decided and what a developer needs to change.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 3.3.7 Redundant Entry (Level A). Declared purposes make it easier to fill information in again in the same process.
• 3.3.8 Accessible Authentication (Minimum) (Level AA). Password fields that work with password managers depend on the same attribute.
• 3.3.2 Labels or Instructions (Level A). Every field also needs a visible label or instructions.
• 4.1.2 Name, Role, Value (Level A). Each field needs a name assistive software can read.

Questions people ask

All WCAG 2.2 criteria, in plain words