The Error Summary at the Top of the Form Is the Whole Fix
On submit, move focus to a summary at the top of the form that lists every error as a link to its field. Inline errors alone leave a screen reader user discovering problems one tab at a time, with no idea how many there are.
Inline errors alone leave people lost
A sighted user submits a form, sees three fields outlined in red, and fixes them top to bottom. A screen reader user submits the same form and hears nothing, because nothing moved focus and nothing announced. They tab forward, find the first error, fix it, resubmit, and discover the second. Then the third. Each submit is a round trip, and each round trip is a chance to abandon the checkout. The inline error did its job for the field it sits next to. It did nothing for the form.
The summary fixes the form-level problem. It sits at the top, it lists every error in the order the fields appear, and each item is a link that moves focus to its field. One announcement tells the user how many problems there are and where they are. The GOV.UK design system, which has tested this pattern with more users than any storefront ever will, treats the summary as the default, not the enhancement, and pairs it with inline errors rather than replacing them.
What a working summary contains
The summary has a heading that says there is a problem, then a list of links, one per error, each naming the field and the problem in plain words. Enter a valid postcode. Choose a delivery option. The link text is the fix, not the field name alone, because the user needs to know what to do, not just where to look. The summary appears only after a failed submit, and it disappears when the form passes. A summary that sits on the page permanently is decoration, and a summary that appears before submit is a lecture.
Order the list the way the fields appear on the page, top to bottom, so the user can work through it in reading order. Do not sort by severity or by field type. The user fixes errors in the order they meet them, and the summary should match that order. Keep the wording short: the field, the problem, nothing else. The explanation belongs next to the field, in the inline error, not in the summary.
The focus move that makes it work
On a failed submit, move focus to the summary heading, with tabindex -1 so the move is legal, and let the screen reader announce the heading and the count. Without the move, the summary is a visual element a screen reader user never reaches, because they are still sitting on the submit button at the bottom of the form. With the move, the user hears there is a problem, hears how many, and can follow the first link straight to the first field. The move is the pattern. The summary without it is a poster.
After the user fixes a field and resubmits, update the summary or remove it. A stale summary listing errors that no longer exist is worse than no summary, because it sends the user to fields that are already correct. Rebuild the list on every submit, and remove the summary entirely when the form passes. The state of the summary must always match the state of the form, or the user stops trusting it, and a summary nobody trusts is a summary nobody uses.
The wording that actually helps
Write the error as the fix. Enter your postcode in the format AB12 3CD beats Postcode is invalid, because the first tells the user what to type and the second only tells them they failed. Avoid blaming the user: the form rejected the input, the user did not do something wrong. And keep the tone flat. A checkout error is a frustrating moment, and a summary that reads like a scolding is the last thing a shopper needs before they decide whether to finish the purchase or leave. The best error summary is boring, specific, and gone as soon as it is no longer needed.
Frequently asked questions
Is an error summary required by WCAG?
Not by name, but success criterion 3.3.1 requires errors to be identified in text, and 3.3.3 requires suggestions where the fix is known. A summary is the established way to meet both at the form level, and the GOV.UK design system treats it as the default pattern.
Do I still need inline errors if I have a summary?
Yes. The summary tells the user how many errors there are and where they are. The inline error tells them what is wrong with the field they are standing on. One without the other leaves half the job undone.
Should the summary appear before the user submits?
No. It appears only after a failed submit, listing the errors that actually happened. A summary shown in advance is guessing, and it teaches users to ignore it before it has anything useful to say.
What should the summary links do?
Each link moves focus to its field, so the user can fix the error immediately. The link text names the field and the problem, in the order the fields appear on the page.