Reviewed October 29, 2026

Error Messages in Store Forms: Say What Broke and How to Fix It

Every store form makes errors. What separates an accessible store from a frustrating one is what happens in the ten seconds after submit. WCAG 2.1 names the expectations with unusual clarity: 3.3.1 Error Identification, the error must be described in text and the item in error identified; 3.3.3 Error Suggestion, where a correction is known, suggest it; and for consequential submissions, 3.3.4 asks for reversibility or confirmation. Against that standard, the common store pattern, a red outline, a banner saying please fix the errors below, and no list of what actually failed, fails in three directions at once, for screen reader users most completely, because they may never be told anything went wrong at all beyond the page reloading.

Move focus to a real error summary

When a submission fails, the customer should land on a summary that states how many errors there are and lists each one, with each list item linking to its field. That pattern serves everyone: a sighted user gets a map instead of a scavenger hunt through a long checkout, and a screen reader user, for whom focus management does the announcing, actually learns the submission failed and why. Sending focus to the top of the form with no summary, or leaving focus on a submit button that no longer exists in the re rendered page, are the two failure modes behind most form abandonment complaints. The summary is not decoration. It is the mechanism by which the error state becomes usable, and building it is a known pattern your developer or platform app can implement once and reuse on every form.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: Alt Text Audits for Product Galleries: A Practical Pass, Accessibility Statements for Small Stores: What to Include, and Keyboard Traps: How to Audit Your Site for Focus That Cannot Escape.

Write errors that identify, locate, and repair

A useful error message has three parts: which field, what is wrong, and, where the format is known, what correct looks like. Card number is incomplete beats invalid field. Postcode does not match the selected country, check for a mistyped character beats an error code or a bare red border. Do not communicate by color alone, which 1.4.1 prohibits as the sole means, and do not clear the fields the customer got right, which punishes slow typists and dictation users by deleting their work. Inline errors beside each field should be linked to the field in code so they are announced when the customer reaches it, and the summary and the inline messages must agree with each other; a summary saying two errors over a form showing one inline message is the kind of inconsistency that ends with the customer phoning you, if you are lucky.

Suggestions and prevention for the expensive fields

Error suggestion means doing arithmetic the customer should not have to do. If a card is declined for an incomplete number, say so. If a password misses a stated rule, name the rule it missed rather than restarting the whole list. Prevention matters most where a format is strict and invisible: date pickers that accept typed input in a stated format, address fields that validate the postcode against the country before submit rather than after, and quantity and discount fields that explain a limit at entry rather than rejecting at payment. Every validation you can move earlier, next to the field and before submission, is an error summary a customer never has to meet. Track which fields generate your failed submissions for a month; the top two are your prevention priorities, and they are rarely the fields the team guessed.

Test the failure path on purpose, with real assistive tech where you can

Nobody on a store team submits a broken form for fun, which is why error states are the least tested surface in most stores. Build the test into your process: for each form in your inventory, submit it empty, submit it with one deliberate format error, and submit it with a value that triggers a server side rejection, and record what a keyboard user and a screen reader user would experience at each step. Check that entered data survives, that focus lands on the summary, that links in the summary reach the fields, and that a corrected resubmission clears the errors completely. Date the test and keep it with your remediation records. When a complaint or a demand letter questions your forms, a dated record of deliberate failure testing is the strongest ordinary evidence a small store can hold.

Frequently asked questions

What is wrong with just highlighting errors in red?

Three things. Color alone is not an accessible means of identification under WCAG, since many users cannot perceive the color change or are not looking at the field when it happens. A screen reader user gets no information from a visual highlight at all. And a highlight without text does not say what is wrong or how to fix it, so even a sighted user is left guessing at formats. Highlights can stay as a visual extra, but each error also needs text, placed at the field and in a summary, that identifies the problem and the correction.

Should focus go to the first error field or to a summary?

A summary is the more robust pattern for forms that can produce several errors at once, because it announces the full state and lets the user choose the order of repairs, with links that move focus to each field. Moving focus straight to the first field works for short forms with a single likely error, but the user may not learn that other errors exist until they fail again. Whichever pattern you choose, focus must go somewhere informative on failure; leaving it nowhere, or on a vanished button, is the actual failure.

How do we handle errors from payment and address services we do not control?

You control more than it feels like. Map the raw service responses, such as gateway decline codes, to plain language messages your store displays, and suppress system codes that mean nothing to a customer. Where a third party iframe or portal renders its own errors, test that experience and raise failures with the vendor in writing; app and portal error handling is a legitimate procurement question. Document what you tested and what the vendor provides. You are responsible for the journey you sell, even where a partner renders a step inside it.

What records should we keep about form error fixes?

Keep the audit inventory of your forms, the errors found with their WCAG references, the fixes made with dates, and the retest results, including the deliberate failure tests. That file is your remediation record. It shows a method, a timeline, and verification, which is what distinguishes a store that is remediating in good faith from one that made cosmetic changes after a complaint. Update it when forms, apps, or checkout settings change, because error handling regresses through exactly those changes, quietly and usually unnoticed until a customer reports it.