The 53 Input Purposes, and What Rule 1.3.5 Actually Asks

There are 53 of them, they live in section 7 of the standard, and the six tables below hold every one. The list is closed. If the thing your field collects is not on it, rule 1.3.5 has nothing to say about that field, and no amount of clever markup earns you credit for it.

The rule itself is two conditions long. A field collecting information about the user has to be able to say what it is for, in code, and the purpose it declares has to be one of the 53. That is it. In HTML the way you say it is the autocomplete attribute, and the token you put in it is the purpose.

Declaring the Purpose Is the Whole Requirement

This is the part almost everybody gets backwards, and it is worth getting straight before you look at the list. Rule 1.3.5 does not ask your form to autofill. It asks your form to be readable by software. Those are different jobs and only one of them is the rule.

So a bank that switches autofill off across a login form can still meet 1.3.5 in full, because the attribute is still sitting there in the markup for anything that wants to read it. W3C says this outright in the test rule for the criterion. Turning the filling off does not stop the value being identifiable.

The reverse holds too, and it costs teams more. A form can autofill beautifully in every browser you try and still fail, because browsers guess. They will fill a field whose tokens are in the wrong order, or misspelled, or invented. A successful autofill is not a passing test, and treating it as one is how a form ships with autocomplete="birthday" on it for two years.

What the declaration actually buys is worth knowing, because it changes how you argue for the work. Once a field says what it holds, software can change how that field looks to the person filling it in. W3C's own examples are a birthday cake drawn beside the date of birth and a telephone drawn beside the phone number, for somebody who reads pictures more easily than words. The tokens mean the same thing in every language, so a reader who cannot read your label still gets a field they recognize.

The Scope Is the Person Filling In the Form

The criterion opens with five words that do most of the scoping work, and they are collecting information about the user. Not information. Information about the user. W3C repeats it in the guidance, repeats it again in the technique, and repeats it a third time in the failure.

So a great deal of what looks like form work is not in scope at all.

• A gift recipient's address. Their street, their postal code, their name. None of it is about the person at the keyboard, so none of it needs a token.
• An emergency contact's phone number. Same reasoning. The field holds somebody else's details.
• A referee's email on a job application. Also outside.
• A "how did you hear about us" box. There is no purpose on the list that fits, so the rule does not reach it.
• An amount you are asking for rather than offering. W3C names transaction-amount as the clearest case of a token on the list that often is not about the user at all.

That last one is the tell that the scope is real rather than a technicality. W3C put a value on its own list and then said in the guidance that a field using it may sit outside the criterion anyway, because what decides is whose information the field holds.

There is a matching allowance for the awkward field. Where one box genuinely takes two purposes, the classic being a login box that accepts either a username or an email address, you may pick one token, or you may leave the purpose off entirely. Both are permitted, and W3C says so in as many words.

The 53 Purposes, in Six Groups

W3C publishes these as one long unordered list with no headings and no count. Six groups follow, in the standard's own order, with the running total after each one so you can see the arithmetic. The token is what you write. The description is what it means.

Names and Titles, Eight Purposes

Sign-In Details, Three Purposes

Eleven so far. The two password tokens are separate on purpose, and password managers rely on the difference to tell a change-password form from a sign-in form.

Company and Address, Twelve Purposes

Twenty-three so far. The four numbered administrative levels are the part people trip on, and the way to hold them is that level 1 is the broadest and the numbers get finer as they rise. Most Western addresses use two of them, which is why address-level2 is your city field and address-level1 is your state or county field.

Payment Details, Twelve Purposes

Thirty-five so far. W3C's own wording says payment instrument rather than card, so the cc tokens cover whatever the field is describing rather than credit cards alone.

Personal Details, Eight Purposes

Forty-three so far. The gap between the token's spelling and its definition is the standard's, not ours, and it comes from the HTML specification the list was copied out of.

Telephone, Email and Messaging, Ten Purposes

Fifty-three. That is the whole list, and it is the same list in WCAG 2.1 and WCAG 2.2. We checked both texts against each other rather than assuming, and they match line for line.

The Token Order Is Strict, and Order Is Where Forms Fail

A value in the autocomplete attribute is not one word. It is a short list of words with a fixed order, and getting the order wrong invalidates the whole thing even when every word in it is real. This is what the automated rule spends most of its time catching.

There are five slots, they go in this order, and only the fourth one is required.

1. 1An optional grouping token, written as section- and then a name you choose. It ties a set of fields together when one page carries two copies of the same form.
2. 2An optional shipping or billing. One or the other, never both.
3. 3An optional home, work, mobile, fax or pager, and only where the next token is one of the contact ones. Those are email, impp, tel and the seven other telephone tokens.
4. 4The purpose itself, exactly one, taken from the 53 above. This is the only slot you have to fill.
5. 5An optional webauthn, last, for a field that should offer a passkey.

So billing address-line1 is valid and address-line1 billing is not. home email is valid and email home is not. work photo is not valid at all, because a contact word can only sit in front of a contact token, and a photograph is not one.

Four more failures come straight from W3C's published examples, and between them they cover most of what we find in real audits. A value with no purpose token in it, such as shipping on its own. A value carrying two purpose tokens, such as address-line1 address-line2 on one field. A value separated by commas rather than spaces. And an extra word tacked on the end, such as email invalid.

What the Automated Rule Cannot See

One ACT rule covers this criterion, and it is narrower than its name suggests. It checks that an autocomplete value that already exists is spelled and ordered correctly. Everything else is yours to test by hand.

Five kinds of field are excluded from it by name.

• Fields whose value is just off or on. Excluded outright. A form that sets autocomplete="off" on all forty fields produces no findings and declares nothing.
• Disabled fields.
• Buttons, checkboxes, radios, file pickers, image inputs, reset and submit. These do not take an autocomplete value in the first place.
• Fields that are neither visible nor in the accessibility tree.
• Elements outside the tab order that carry no widget role.

And then there are the two failures no scanner will ever raise for you. A field collecting the user's own phone number with no token at all is invisible to the rule, because the rule only looks at values that are present. A field carrying a token that is perfectly valid and completely wrong, such as email sitting on a surname box, passes every automated check there is. Both are documented failures of the criterion.

W3C is straight about what this adds up to. The rule's own outcome mapping says that a page where every element passes leaves the criterion needing further testing. A pass here is a spelling result, not a verdict.

One Valid HTML Token Is Not on WCAG's List

The 53 were copied out of HTML 5.2 in 2018 and frozen there. The HTML specification is a living document and has kept moving, so the two lists have drifted apart by exactly one token. HTML has 54 field names now. The extra one is one-time-code, for the box where somebody types the six digits from a text message.

Nothing runs in the other direction. Every one of WCAG's 53 is still valid HTML. So autocomplete="one-time-code" is correct markup, it is the right thing to write on a two-factor field, it will not fail the automated rule, and it earns you nothing under 1.3.5 because the purpose is not on the frozen list. Write it anyway. It helps password managers, and a one-time code is barely information about the user to begin with.

What to Say When Security Objects to Autofill

This objection arrives on almost every banking, insurance and health project, and it is usually aimed at the wrong thing. Nobody is asking you to switch autofill on. The rule is satisfied by the attribute being there. Still, the argument tends to happen, so here is what W3C's own technique says about it.

• Saved data works on one computer, one user account and one browser. It does not travel between logins.
• Saving is opt-in, and the person is asked the first time.
• The form is never submitted automatically. The person sees the values before anything goes anywhere.
• Clearing saved form data takes a few seconds in browser settings, and private browsing avoids it entirely.
• Browsers and password managers already guess at your fields and fill them in. The tokens do not create that behavior. They make it accurate.

That last point is the one that ends the conversation. An unlabelled field does not stop a password manager. It just means the password manager guesses, and a wrong guess puts a card number somewhere you did not want it.