Reviewed November 6, 2026

Autocomplete on Checkout Fields: The WCAG 1.3.5 Fix That Fills the Form for You

A checkout form without autocomplete attributes is a form the browser cannot help with. The shopper types their name, address, and card number by hand, on a phone, while the browser sits there holding all of it, unable to offer it, because nobody told the form what each field is. WCAG 1.3.5, Identify Input Purpose, exists for exactly this failure, and it is a Level AA requirement.

The failure is invisible to the merchant, because the form works. It works slowly, with more typing, more errors, and more abandoned checkouts, and the merchant never sees the browser offer that did not appear.

What the criterion actually asks for

Criterion 1.3.5 requires the purpose of each input that collects user information to be programmatically determinable. In practice that means the autocomplete attribute with the right token: given-name, family-name, email, tel, address-line1, address-line2, postal-code, cc-number, cc-exp. Browsers use the tokens to offer saved data, and password managers use them to fill credentials.

The tokens are a fixed list, and the wrong token is nearly as bad as none. An address field tagged as a name field will offer the shopper their name where the street belongs, which is worse than no offer at all. The check is not whether the attribute exists. It is whether the token matches the field.

Where Shopify stores fail it

Shopify's own checkout handles its fields, but custom forms are the gap: newsletter signups, account registration, contact forms, address forms in apps, and any custom checkout extension that adds a field without a token. The fix is one attribute per field, in the theme or the app code, and it is a small job once the gap is found.

The gap survives because nobody tests it. The form works with a mouse and a keyboard, the data arrives, and the missing attribute never produces an error. It produces a slower checkout, which shows up in the abandonment rate, not in the error log.

How to check it in ten minutes

Open the form, inspect each input, and confirm the autocomplete attribute and the token. Then test with a browser that has saved addresses and watch whether it offers to fill. The failure shows up as silence where the offer should be. Check the templates that matter: account registration, contact, newsletter, and any custom form the store added.

Related reading

Related reading: Checkout Form Errors: Naming the Field Is Only Half the Job, Consistent Help: WCAG 3.2.6 and the Wandering Contact Link, and Dragging Movements Need a Second Way In: WCAG 2.5.7 on Storefronts.

Frequently asked questions

What is autocomplete in WCAG?

It is the autocomplete attribute on a form field, with a token that says what the field collects, like given-name or postal-code. Criterion 1.3.5 requires it on fields that collect user information, so browsers and password managers can offer saved data.

Which fields need autocomplete attributes?

Any field that collects information about the user: name, email, phone, address lines, postal code, city, country, and payment details. Fields that collect information about the order, like a gift message, do not need one.

Does autocomplete help screen reader users?

Yes, indirectly. A field with a correct autocomplete token is also a field whose purpose is clear to assistive technology, and the saved-data offer saves the user from typing, which is the hardest part of a form for many people.

Can I add autocomplete without a developer?

Usually not, because the attribute lives in the theme or app code. A merchant can check the form and file a precise report, listing each field and the token it needs, which is half the work. The edit itself is one attribute per field.