Checkout Error Summaries: The Focus Move That Decides Whether Keyboard Users Finish

A shopper submits a checkout form with four errors, and nothing happens that they can perceive. The card field turns red, the error summary sits at the top of the page unannounced, and the keyboard user has no idea where the problem is. That is a WCAG 3.3.1 failure, and it is also a lost sale, because the shopper cannot fix what they cannot find.

3.3.1 says identified, and in text

WCAG 3.3.1, Error Identification, Level A, says that when an input error is automatically detected, the item in error is identified and the error is described to the user in text. Two words matter: identified, which field, and text, not just a colour change. The W3C understanding document is explicit that a visual indicator alone is not enough. A red border on an invalid field communicates nothing to a screen reader user, and the error has to exist as text, associated with the field it describes.

That is the bar, and most checkouts fail it in the same place. The card-number field turns red with no message, or an error summary appears at the top of the page but is never announced, because focus never moves to it and the field does not reference it. A sighted mouse user might scroll up and find it eventually. A keyboard or screen reader user has no reason to know it is there, and will submit the form again, get the same silent failure, and leave. The sale is lost at the exact moment the form was supposed to help.

The summary pattern that actually works

When a form fails on submit, the strongest pattern is a focused error summary at the top of the form. Move focus to a heading announcing how many errors were found, list each error as a link that jumps focus to the offending field, and keep the inline per-field messages in place, because the summary alone does not satisfy 3.3.1 for each input. This satisfies 3.3.1 and 4.1.3 together, and it helps sighted keyboard users as well as screen reader users.

GOV.UK has published this pattern for years, and its design system error summary remains the cleanest public reference implementation. The pattern is not new, and it is not hard. What is hard is remembering to move focus, because a summary that appears without a focus move is invisible to the people it was built for. Test it with a keyboard: submit an empty form, and listen for whether the summary is the first thing you hear. If it is not, the pattern is not implemented.

Tie the message to the field, or it is not tied

An error summary is not a substitute for per-field association. Each error needs its own aria-describedby association, pointing at the error text, and aria-invalid set to true on the input itself. The message is then announced when the field receives focus, which is how a screen reader user learns what is wrong and where. Inline errors tied to a field this way do not strictly need a live region, because the message is announced on focus. Errors that appear without focus, such as a submit-time summary or a server-side failure, absolutely do, which is where 4.1.3 comes in.

The timing matters too. Validating on the first keystroke teaches screen reader users that the form is hostile, because the error is announced before they have finished typing. The pattern that works is to validate on blur once, then re-validate on each keystroke after the field has been marked invalid, so the error clears the moment the value is corrected. That is a small detail, and it is the difference between a form that feels broken and one that feels careful.

Test it the way the shopper will hit it

Open the checkout with a keyboard only, no mouse, and submit an empty form. Focus should land on the summary or the first invalid field. Tab through the summary links and confirm each one lands on its field. Then fill the form with a deliberately wrong card number and submit again, and confirm the error message appears as text next to the field, not just as a red border.

Then do the same test with a screen reader, NVDA with Chrome or Firefox is free on Windows, and listen. If the summary is never announced, or the error is announced without saying which field it belongs to, the checkout fails 3.3.1, and the fix is a focus move and an aria-describedby, not a redesign. That is a day of work, and it is the cheapest accessibility fix in the whole checkout.

Frequently asked questions

Is a red border enough for a form error?

No. A red border communicates nothing to a screen reader user or to anyone who cannot perceive that particular red. The error has to exist as text, associated with the field it describes, and the field must be identified. Colour alone fails 3.3.1 on its own.

Where should focus go when a checkout form fails?

Move focus to an error summary at the top of the form listing every error as a link, and keep the inline per-field messages in place. The summary alone does not satisfy 3.3.1 for each input. A summary with no focus move is decoration.

How do I associate an error message with its field?

Use aria-describedby to tie the error text to the field, and set aria-invalid to true on the input. The message is then announced when the field receives focus. Do not rely on a live region alone for inline errors, and do not rely on a tooltip that disappears.

What is the most common checkout error failure?

The classic one is a card-number field that turns red with no message, or an error summary at the top of the page that is never announced because focus never moves to it. A sighted mouse user might scroll up and find it eventually. A keyboard user has no reason to know it is there.