Reviewed November 1, 2026

Checkout Field Error Messages: Wording and Placement That Let People Finish

Put the error in text, next to the field, in words that say what to fix: Card number is incomplete, check the digits, beats Invalid input. Connect it to the field with aria-describedby, mark the field aria-invalid, move focus to an error summary on submit, and never identify the problem by color alone. Errors must survive a page reload of the checkout step and must be announced, not merely shown, or screen reader users will submit in circles without ever learning why.

Checkout is where an accessibility failure stops being an inconvenience and becomes a lost order with a name attached. Field errors are the sharpest case. A shopper submits, the page shakes or redraws, two fields gain red borders, and nothing else happens. Sighted users play spot the difference across twenty fields. Screen reader users get silence, or a page that sounds identical to the one that just failed. The store's analytics record an abandoned checkout and blame price sensitivity.

Error handling is not a design flourish in WCAG. It is three named criteria working together: 3.3.1 Error Identification, 3.3.3 Error Suggestion, and 1.4.1 Use of Color, with focus management doing the practical work the criteria assume.

Wording: name the field, the problem, and the fix

Invalid is not an error message, it is a mood. A usable message has three parts: which field, what is wrong in plain terms, and how to correct it when the correction is not obvious. Expiry date is in the past, enter a future date. Email address needs an @ and a domain, like name@example.com. Postal code does not match the selected country. Each one lets the shopper act without guessing, which is exactly what 3.3.3 asks for when it requires suggestions where the correct format is known.

Mind the tone while you are at it. Error text written like an accusation, You entered an invalid card number, raises the stress of a payment form that is already the tensest screen in the store. Neutral, instructional wording measurably reduces form abandonment in usability testing, and it costs nothing. The message is a set of directions. Write it like directions you would give a person standing next to you.

Placement and announcement: make the error findable by everyone

Place the message immediately after its field in reading order, associated with aria-describedby so a screen reader speaks it when the field receives focus, and set aria-invalid on the field itself. On submit with errors, move focus to a summary at the top that counts and lists the problems with links to each field: 2 errors in this form, followed by anchored items. That pattern, used by government design systems for years, serves everyone: sighted users get a map, keyboard users get transported instead of stranded, screen reader users get the announcement the redraw never gave them.

Never clear entered data on a failed submit, and never let the error exist only as a border color, an icon, or a tooltip that vanishes. And test the timed trap: some checkouts wipe or refresh the step after inactivity, errors included. A shopper returning to a blank, unexplained form starts over or leaves. Preserving input and its error state is both a WCAG aligned behavior and basic commercial sense.

Test the failure path, not just the happy path

Audits miss error states because auditors test successful journeys. Deliberately fail your checkout in every way you can invent: expired card dates, mismatched countries and postal codes, empty required fields, a card number one digit short. Do each with the keyboard alone and once with a screen reader running, and count how many seconds it takes to learn what is wrong and where. If the answer involves hunting, the error handling is the bug.

Include the payment provider's fields in the test. Iframe based card fields are a common blind spot where the store's careful error pattern stops at the iframe boundary. You cannot fully control a provider's internals, but you can choose providers partly on their error accessibility, and you can handle the surrounding fields, summary, and focus behavior so the overall journey still works.

Frequently asked questions

Does a red border count as identifying an error under WCAG?

No. Color alone fails 1.4.1 Use of Color, and a border gives no text identifying which input is wrong or how to fix it, which 3.3.1 and 3.3.3 require. The error must be described in text and programmatically associated with the field.

Should errors appear as the shopper types or after submit?

Both have a place. Gentle inline checks after a field loses focus can catch format problems early, but aggressive live validation that flags a field while the shopper is still typing creates noise. A clear summary plus field messages on submit remains the required backbone.

What should an error summary contain?

A count of the errors, a plain list naming each problem, and a link from each item to its field so keyboard and screen reader users can jump directly to the fix. Focus should move to the summary when it appears so it is announced immediately.

Are Shopify checkout error messages accessible by default?

The hosted checkout handles many of these patterns reasonably, but stores still control surrounding content, custom fields via checkout extensibility, and pre checkout forms like account creation and cart details. Audit the whole journey, not only the payment step.