Input purpose

A label tells a person what a field wants. An autocomplete token tells software the same thing, from a fixed list: name, email, tel, postal-code, cc-number, bday, and a few dozen more. WCAG 2.2 makes the tokens a requirement at AA for fields collecting information about the user, which is a rare success criterion where the conforming markup is one attribute and the benefit is immediate.

The obvious payoff is autofill. A form with the tokens declared fills from the profile the browser already holds, which is worth most to the people for whom typing is expensive: anyone using a switch, an on-screen keyboard, voice input, or working through a tremor. The less obvious payoff is personalisation. Because the token names a known concept rather than an arbitrary string, an assistive tool can restate the field in its user’s own terms: swap the wording, or put a familiar pictogram beside it, which is the whole point of the criterion sitting under the “adaptable” guideline rather than under a text alternative one.

The tokens do not replace anything. A field still needs its own visible label and its label association, because a token is not a name and a screen reader does not speak it. Nor is it the same feature as address autocomplete, which is a live lookup service suggesting whole addresses inside one field. The token is a static declaration of what this field means; whether the browser then offers a saved value, a lookup, or nothing at all is the browser’s business.

Two practical notes. Get the token right or leave it off, since a field labelled “Company” that declares name will be filled with a person’s name forever, and a wrong token is worse than a missing one. And treat the whole thing as a first line of defence against redundant entry: the more of a checkout the browser can complete from what it already knows, the less of your form is a memory test.