The HTML autocomplete Attribute: Meeting WCAG 1.3.5 on Checkout Forms
A checkout form’s first name field and its shipping city field are both <input type="text">. Visually, a sighted shopper tells them apart by the label sitting next to each one. Programmatically — to a browser deciding what to offer for autofill, or to assistive technology trying to present the field in a different way — they’re identical unless something in the markup says otherwise. That “something” is the HTML autocomplete attribute, and it’s the specific mechanism WCAG Success Criterion 1.3.5 Identify Input Purpose requires.
Quick answer: SC 1.3.5 (Level AA) requires that “the purpose of each input field collecting information about the user can be programmatically determined” — not just visually labeled, but identifiable by software. For standard checkout fields (name, email, phone, address, payment), the WHATWG HTML Living Standard’s autofill specification defines a fixed set of autocomplete token values (given-name, street-address, cc-number, and so on) built for exactly this purpose. Adding the correct token to each field satisfies the criterion, lets browsers autofill the form correctly, and lets assistive technology present the field’s purpose through icons or alternate renderings instead of relying on visible label text alone.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question — consult qualified counsel for legal risk questions.
Why a visible label isn’t what SC 1.3.5 is asking for
It’s easy to read 1.3.5 and assume a <label> already satisfies it — the field’s purpose is right there in the text. But the Understanding doc is specific about what “programmatically determined” means: information “determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities.” A visible label is one modality — text on screen. It doesn’t tell a browser’s autofill engine that a field expects a street address rather than a company name, and it doesn’t let a screen reader or browser extension substitute a different presentation (an icon, a picker, a translated label) for the same field. The criterion’s intent section calls out cognitive disabilities specifically: someone who has trouble parsing an unfamiliar label benefits when the browser or an assistive tool can recognize the field’s purpose independently of how that label happens to be worded.
The type attribute gets partway there — type="email" or type="tel" already tells a browser something. But 1.3.5’s own Understanding doc notes that autocomplete provides “a more fine-grained definition or identification of purpose than the type attribute” — type="text" alone can’t distinguish a first name from a city from a company name, all three of which are legitimately plain text inputs.
The token set that covers a checkout form
The HTML autofill specification defines a fixed taxonomy of field-name tokens, not a free-text hint — a browser or assistive tool can only rely on autocomplete if the value is drawn from that defined set. WCAG Technique H98 demonstrates the pattern directly, including this worked example:
<label for="fname">First Name</label>
<input autocomplete="given-name" id="fname" type="text">
<label for="lname">Last Name</label>
<input autocomplete="family-name" id="lname" type="text">
<label for="cc-num">Credit card number:</label>
<input autocomplete="cc-number" id="cc-num" type="text">The tokens that cover a typical checkout form’s fields, per the HTML spec:
- Name:
name,given-name,family-name,honorific-prefix,honorific-suffix,nickname - Contact:
email,tel - Address:
street-address,address-line1,address-line2,address-line3,address-level1(state/province),address-level2(city),postal-code,country - Payment:
cc-name,cc-number,cc-exp,cc-exp-month,cc-exp-year,cc-csc
H98’s own success requirement is narrow and checkable: the field has “a valid autocomplete attribute and value pair,” and “the purpose of the form field indicated by the label corresponds with the autocomplete token” — a city field carrying autocomplete="postal-code" fails the technique even though an autocomplete attribute is present, since the token has to actually match what the field collects.
Shipping vs. billing: the token that most checkout forms get wrong
A checkout page usually has two address blocks — shipping and billing — and this is where a bare token list stops being enough. The HTML spec’s answer is a scope modifier: field names combine with an optional prefix so the same underlying purpose (street-address) can be tagged as belonging to one group or another. Per the spec, “the autofill scope identifies the group of fields whose information concerns the same subject,” and the prefixes combine in order — an optional section-* grouping token, then shipping or billing, then (for tel/email only) a contact-type token like home or work, then the field name itself:
<fieldset>
<legend>Shipping address</legend>
<label for="ship-street">Street address</label>
<input autocomplete="shipping street-address" id="ship-street">
<label for="ship-city">City</label>
<input autocomplete="shipping address-level2" id="ship-city">
<label for="ship-zip">ZIP / postal code</label>
<input autocomplete="shipping postal-code" id="ship-zip">
</fieldset>
<fieldset>
<legend>Billing address</legend>
<label for="bill-street">Street address</label>
<input autocomplete="billing street-address" id="bill-street">
</fieldset>Without the shipping/billing prefix, a browser has no reliable way to tell two street-address fields on the same page apart — it may offer to autofill both with the same value, or autofill the wrong one, which is a worse outcome for everyone (not just assistive-technology users) than no autofill at all. This is also the mechanism behind WCAG SC 3.3.7 Redundant Entry, which Quietramp’s redundant-entry article covers for the “same as shipping” checkbox pattern specifically — correctly scoped autocomplete tokens are what let a browser (or a same-as-shipping script) actually know which value belongs where.
Login and account fields need their own tokens
Checkout isn’t the only place this matters. A guest-checkout-vs-login toggle, or an account-creation step, needs autocomplete="username", autocomplete="current-password", and autocomplete="new-password" — distinct tokens for what look like near-identical password inputs. Quietramp’s accessible-authentication article covers the login-flow requirements in full; this article’s scope is the checkout form itself.
What doesn’t need a token
SC 1.3.5 applies specifically to “input fields collecting information about the user” — not every text field on a page. A gift card or promo code field isn’t collecting information about the shopper, so it falls outside this criterion; Quietramp’s gift-card and promo-code article actually recommends autocomplete="off" there, for an unrelated reason (stopping a browser from suggesting a previously-typed code). The two guidances aren’t in tension — one covers fields the criterion applies to, the other a field it doesn’t.
What a scanner catches, and what still needs a person
An automated scanner can confirm an autocomplete attribute exists and that its value is a real, spec-defined token. It generally cannot confirm the token matches what the field actually collects — autocomplete="family-name" on a field labeled “Company” is syntactically valid and passes a scan, but fails H98’s own success requirement, since a browser will confidently autofill the shopper’s last name into a company field. That gap, between “the attribute exists” and “the attribute is correct,” is what a manual pass over the rendered form has to close.
Where to start
In rough order of effort: add the correct token from the checkout-field list above to every name, contact, address, and payment field; add shipping/billing scope prefixes anywhere the same field type appears twice on one page; add username/current-password/new-password to login and account-creation fields; then test by actually triggering browser autofill (not just inspecting markup) to confirm each field fills with the value it’s supposed to, not a neighboring field’s value.
FAQ
Does autocomplete=“off” ever conflict with SC 1.3.5? Only on fields the criterion actually covers. Turning autofill off on a field that collects user information (name, address, payment) removes the benefit 1.3.5 is written for. Turning it off on a field that doesn’t collect user information — a promo code, a search box — is unrelated to this criterion.
Is a correct type attribute (type="email", type="tel") enough on its own?
No. type helps with input validation and mobile keyboard layout, but per 1.3.5’s own Understanding doc, autocomplete is what provides fine-grained purpose identification — type="text" alone can’t distinguish a first name from a city.
Do these tokens do anything for screen reader users directly, or is this purely a browser-autofill feature? Both. Browsers use the tokens for autofill, and per 1.3.5’s intent, user agents and assistive technologies can use the same programmatically-exposed purpose to present the field differently — for instance, with a recognizable icon — independent of the browser’s autofill feature.
Get your checkout form’s fields checked by a person, not just a parser
Quietramp’s $890 audits include a manual pass through checkout forms — confirming that each field’s autocomplete token actually matches what it collects, not just that a token is present. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not constitute a legal compliance determination under the ADA or any other standard — consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.