Accessible Address Autocomplete and Lookup Fields at Checkout

Address lookup looks like a shortcut until the suggestion list cannot be used with a keyboard or screen reader. What WCAG requires from autocomplete fields, and how to test them.

Address autocomplete fails in a very specific way. The shopper types three letters, a list appears under the field, and then nothing on the keyboard reaches it. Arrow keys scroll the page. Enter submits the whole checkout form with half an address in it. A screen reader says nothing at all, because the list was never announced as a list. The field looked modern in the demo and it is unusable for the people who most need the shortcut.

WCAG 2.2 does not ban autocomplete. It sets the conditions the widget has to meet: 1.3.1 Info and Relationships for the list structure, 2.1.1 Keyboard for full operation without a mouse, 4.1.3 Status Messages for announcing how many suggestions appeared, and 1.3.5 Identify Input Purpose so the browser itself can fill name, street, city, and postcode fields correctly. Most lookup widgets pass none of those four on the first test, which is not an argument against the feature. It is an argument for testing the actual component instead of the sales page.

Test the list, not the field

Start with the keyboard alone. Tab into the address field, type a partial street name, and keep your hands off the mouse. Can you arrow into the suggestions, hear which one is highlighted, press Enter, and land back in a sensible place with the town and postcode filled? If Enter triggers the next checkout step instead of selecting a suggestion, that is a defect, not a preference. Note it against 2.1.1 and 2.4.3 Focus Order, with the exact keystrokes that failed.

Then run the same flow with a screen reader. A working widget announces something like four results available, updates that count as you keep typing, and reads the highlighted option. Silence is the common failure. Developers often render suggestions as clickable divs with no listbox role, no aria-expanded state, and no live region, so assistive technology has nothing to report. The fix is structural, not cosmetic, and it belongs in the component, not in a note on the accessibility statement.

Keep the manual route open

The second test matters just as much. Clear the field and try to type a full address by hand, ignoring the lookup entirely. Some implementations punish that choice: they clear fields the lookup did not fill, overwrite a typed postcode, or flag a valid address as unrecognised because it is a new build that the database has not caught up with. A shopper in a new housing development should not need a workaround to buy something.

Manual entry is also the fallback for addresses the database formats badly, flats with sub-building names, and business addresses with a unit line the lookup drops. Keep every address line editable after a selection, keep the country field reachable before the lookup starts guessing, and never lock a field because the widget filled it. Locked fields turn a small database error into a checkout abandonment, and abandonment at the address step is rarely reported as an accessibility problem even when that is exactly what it is.

What to put in the defect report

Write the report the way a developer can act on it. Name the component and version if you know it, the browser and assistive technology used, the criterion, and the keystroke sequence. Address lookup failures get bounced between the store team and the app vendor for months when the report just says checkout is not accessible. They get fixed in a release when the report shows the list has no keyboard path and no status announcement.

Re-test after every app update, not just theme changes. Lookup widgets update silently, and a fix for suggestion speed can quietly remove the live region that took three tickets to get added. Put this field on the monthly spot check list alongside the cart drawer and the search box.

Related reading: Accessible Password Creation: Where Signup Forms Lock People Out, Accessible Gift Message and Delivery Instruction Fields at Checkout, Testing Reflow at 400 Percent Zoom Before the Sale Starts.

Frequently asked questions

Does WCAG require address autocomplete on checkout forms?

No. WCAG 1.3.5 requires that when a field collects a known purpose like street address or postcode, that purpose is programmatically identifiable, usually with the right autocomplete attribute. A lookup widget is optional. If you add one, it still has to be keyboard operable and announced properly.

What should a screen reader announce when suggestions appear?

A status message with the number of results, and the highlighted suggestion as you move through the list. The list itself should expose a listbox or equivalent structure with an expanded state on the field. Silence, or reading the whole page again, means the widget was built for sighted mouse users only.

Can we keep the lookup if manual entry still works?

Manual entry helps, but it does not excuse a keyboard trap or an unannounced list in the widget itself. Keep both routes working. The lookup has to be operable, and the typed route has to stay editable and accepted even when the database does not recognise the address.

How often should address lookup be retested?

After every app or theme update that touches checkout, and on a regular monthly spot check. These widgets update in the background, so a component that passed in September can lose its keyboard support in an October release without anyone on the store team changing a setting.