When a Cart Error Wipes the Form: An Accessibility Failure, Not a Nuisance

2026-10-29

One wrong digit in a postcode, and the whole form comes back empty. Name, address, email, all gone, with a banner that says please check the highlighted fields, highlighting fields that no longer contain anything to check.

Every shopper hates this. For some shoppers it ends the purchase, because the cost of re-entering is not thirty seconds of typing. It is ten minutes of switch scanning, dictation, or careful keyboard work, spent twice.

Why data loss is an accessibility issue, specifically

WCAG 2.1 criterion 3.3.1 requires that input errors be identified in text, and 3.3.3 requires suggestions for fixing them when known. Wiping the form makes both harder to satisfy in practice: the user cannot see what they entered, compare it with the suggestion, or correct a single character.

There is also a plain cognitive load argument practitioners make without needing a criterion number. Reconstructing an address from memory under time pressure, sometimes with a session timer running, is a memory test. Checkout is not supposed to be a memory test.

What good recovery looks like, field by field

Keep every valid field exactly as entered. Put the error text next to the failed field, link a summary at the top directly to each problem field so keyboard users can jump to it, and move focus to the summary on submit so screen reader users hear the count and the list first.

Suggestions should be concrete: postcode should be five digits, or that expiry date is in the past. A suggestion is not the word invalid wearing a uniform. Where the system knows the correction, offering it, with the user's original entry still visible, is the strongest form.

The session timeout trap that compounds it

Re-entry takes longest for the shoppers least able to afford it, and many carts run a stock reservation or session timer in the background. WCAG 2.2 criterion 2.2.1, timing adjustable, and 2.2.6 on timeouts both point the same way: warn before time expires and make extending it possible without losing data.

If your cart must expire, save the basket and the entered details server side where privacy rules allow, and say what will happen before it happens. A silent wipe at minute twenty is a design decision, not a technical necessity.

A test any store can run this week

Fill the cart form with one deliberate error, submit, and record three things: what data survived, where focus went, and whether the error named the field and the fix in plain text. Do it with a keyboard only, then with a screen reader.

Most stores have never run this test. The results are usually embarrassing within ninety seconds, which is useful, because every fix on this list is cheaper than the abandoned orders it causes.

Frequently asked questions

Does WCAG forbid clearing a form after an error?

Not in those exact words, but clearing data undermines 3.3.1 and 3.3.3, which require errors to be identified and corrections suggested. A shopper cannot correct an entry they can no longer see. Preserving input is the accepted way to meet the intent.

Where should focus go after a failed submit?

To an error summary at the top of the form that states how many problems there are and links to each one. That gives keyboard and screen reader users a map instead of leaving them to hunt field by field.

What makes a good error suggestion?

A specific, plain language statement of what the field needs, like a five digit postcode or a future expiry date. The word invalid on its own tells the shopper nothing they did not already know from the failure.

How do timeouts interact with accessible checkout?

Shoppers using assistive technology often need more time, so WCAG requires warnings and extensions for time limits in most cases. Warning before expiry and preserving the basket and details prevents a slow, careful shopper from being punished for being slow and careful.