Reviewed November 4, 2026

Checkout Form Errors: Naming the Field Is Only Half the Job

When a checkout field fails validation, WCAG 2.2 criterion 3.3.1 (Error Identification, Level A) requires that the field in error be identified and the error described to the user in text. Criterion 3.3.3 (Error Suggestion, Level AA) goes further: when a correction is known, suggest it, such as the expected format for a date or postal code. A red border alone fails both.

The shopper typed a card number with spaces, your checkout rejected it silently, tinted the field red, and kept the payment button dead. She is now guessing. That small moment fails two separate success criteria, and it also happens to be where measurable checkout abandonment lives.

Error handling is unglamorous criteria work. Nobody wins design awards for it. But 3.3.1 and 3.3.3 are plain about the obligation, and checkout is the worst place on a storefront to be vague, because the user cannot route around the form. There is no other door.

Identification means words, in the right place

The error must be described in text and associated with the field, not conveyed by color, icon, or a shake animation alone. Screen reader users need the message programmatically tied to the input, with aria-describedby or an equivalent technique, and announced rather than left to be discovered by tabbing backwards.

Placement matters for sighted users too. A single error summary at the top with no field level messages forces hunting. Field level text under each problem, plus a summary that moves focus and links to each field, is the pattern that serves both groups without duplication of effort.

Suggestion is a separate duty, and it is practical

Criterion 3.3.3 applies when the system knows what right looks like. Expiry dates want MM/YY stated in the message, not just invalid date. Postal codes want the expected pattern for the selected country. Email fields want the missing element named, as in the address needs an @ symbol and a domain.

Where 3.3.3 has limits, they are also defined: suggestions can be skipped when they would compromise security or the purpose of the content. A password field does not owe the user its correct value. It still owes a statement of the rules it is enforcing, ideally shown before the error happens.

Do not clear the form, and do not blame the user

Two adjacent habits complete the job. Preserve everything the shopper entered when validation fails; retyping a full address because one digit failed is a Level A adjacent cruelty covered in spirit by 3.3.7 Redundant Entry in WCAG 2.2 for information entered earlier in the same process.

Tone is free. Enter a valid expiry date using MM/YY outperforms Wrong input in every test of user patience ever run informally at a support desk. The criteria require identification and suggestion. They do not require the message to sound like an accusation, so do not let it.

Frequently asked questions

Is a red outline enough to identify a form error?

No. Criterion 3.3.1 requires the error to be described in text and the item in error identified. Color or styling alone is not perceivable to all users and does not say what is wrong.

What does error suggestion require at checkout?

Criterion 3.3.3 requires a known correction to be suggested, such as the expected format for a date, card, or postal code field, unless giving the suggestion would compromise security or the content's purpose.

Should error messages be announced to screen readers?

Yes, in practice. The message should be programmatically associated with the field and presented so assistive technology users learn of it when it appears, rather than having to search the page for what changed.

Can I validate fields as the user types?

Inline validation is allowed and can help, provided errors are identified in text, suggestions are given where known, and the implementation does not move focus or punish partial input like a half typed date.