Perceivable Guideline 1.3 Adaptable

1.3.5 Identify Input Purpose

Fields that ask for a person's own details must say what they are for

Level AA 1 automated check

What it asks for, in plain English

When a form asks for something about the person filling it in, such as their name, email, phone number, address, date of birth, username or card number, the field has to say so in code, in a way browsers and assistive tools understand. In HTML that is the autocomplete attribute with a standard value like email, given-name, postal-code or tel.

This lets browsers and password managers fill the field correctly, and lets assistive tools swap the label for a familiar icon or the person's own wording. It only applies to information about the person using the form, not to fields like 'order reference' or 'your message'.

A label that says Email is not enough on its own; the point is a machine-readable purpose that is the same on every site.

This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 1.3.5 page has the full intent, techniques and definitions.

Who it affects

Someone with a memory or learning difficulty lets the browser fill their address rather than recalling and typing a postcode under pressure.

A person with a tremor or limited hand movement avoids typing twelve fields by hand on every checkout.

Someone with aphasia using a tool that replaces labels with icons sees a familiar envelope symbol instead of a word they struggle to read.

Example

Broken
<label for="fn">First name</label> <input id="fn" type="text">
<label for="em">Email</label> <input id="em" type="email" autocomplete="e-mail">
<label for="pc">Postcode</label> <input id="pc" type="text" autocomplete="off">

The first field has no declared purpose, the second uses a value that is not in the standard list, and the third actively blocks filling.

Fixed
<label for="fn">First name</label> <input id="fn" type="text" autocomplete="given-name">
<label for="em">Email</label> <input id="em" type="email" autocomplete="email">
<label for="pc">Postcode</label> <input id="pc" type="text" autocomplete="postal-code">

Standard tokens. The browser now offers to fill all three from saved details.

How to check it

  1. Find every form that asks for personal details: sign-up, checkout, contact, profile.
  2. Inspect each field and check it has an autocomplete attribute with a value from the HTML standard list (given-name, family-name, email, tel, street-address, postal-code, cc-number and so on).
  3. Fill the form in a browser that has saved details. The browser should offer to fill each personal field with the right thing.
  4. Watch for autocomplete="off" on personal fields, which is often added to stop the browser being 'annoying' and breaks this for everyone.

What Websight checks for 1.3.5

Websight runs this automated check for 1.3.5:

Websight's autocomplete check flags values that are not valid tokens, such as e-mail or firstname, and tokens that do not fit the field type. It cannot tell that a field asking for an email address has no autocomplete attribute at all, because it does not know what the field is for.

Practical tips

  • Use the exact token names from the HTML standard; they are case-insensitive but the spelling matters.
  • Do not add autocomplete="off" to fight the browser. If you need to stop filling on a one-time code, use one-time-code instead.
  • Add autocomplete to the fields in your shared form components once and every form gets it.

Scan your page and see where 1.3.5 stands

Websight gives a score out of 100, explains each automated finding in plain English, and lists the checks a person still needs to do.

Add Websight to Chrome

Free scans, no account, nothing leaves your computer. Automated tools find only part of the problems; the extension says so on every report.