Error Suggestions That Actually Help: WCAG 3.3.3 in Checkout

WCAG 2.2 criterion 3.3.3 requires an error suggestion when the fix is known. Most checkout forms fail it with red borders and a generic message.

A shopper submits a checkout form and the page reloads with a red outline around the card field and the words invalid input. She stares at it. The number is right, the expiry is right, and nothing on the page says what is actually wrong. That is a failure of WCAG 2.2 Success Criterion 3.3.3, Error Suggestion, and it is also a lost sale, because the shopper who cannot tell what to fix will not guess three times.

The criterion only applies when the site knows the answer, or can work it out. When the fix is known, the form has to say it. When it is genuinely unknown, a plain error identification is enough. The line between the two is where most checkout forms go wrong.

What counts as a suggestion

Criterion 3.3.1, Error Identification, is the floor: the field in error must be identified in text, not by colour alone, and the error must be described. Criterion 3.3.3 goes one step further. If the system can suggest a correction, it must offer one. A postcode that does not match the selected country is a known fix. A card number with fifteen digits where sixteen are expected is a known fix. A password that fails a stated rule is a known fix, and the suggestion is the rule itself.

The suggestion does not have to be perfect. It has to be specific enough to act on. Suggesting the correct postcode format, naming the field that conflicts, or pointing out that the expiry date is in the past are all suggestions. Repeating invalid input is not one, and neither is a red border with no words attached.

The patterns that fail on real stores

The most common failure is the silent field. The form marks the card number red and says nothing, or the error summary at the top lists the field name but not the problem. Screen reader users get the worst of it: focus stays at the top of the page, the error is announced nowhere, and the only signal is a colour change they cannot perceive.

The second failure is the suggestion that blames the user for the system's own rule. A discount code field that rejects a code with a space at the end, without trimming it or saying so, is the store's bug dressed up as the shopper's mistake. Trim whitespace, accept the code, and save the error message for a code that genuinely does not exist.

Building it right

Put the error text next to the field, in text, and link it with aria-describedby so a screen reader announces it when the field receives focus. Move focus to the error summary on submit, and make the summary a list of links that jump to each field. Announce new errors with a live region, but do not announce the same error twice.

Test with a keyboard and a screen reader, not just by looking. Submit an empty form, submit a form with a wrong postcode, submit a form with an expired card date, and check that each failure names the field, states the problem, and offers the fix. Three test cases cover most of what 3.3.3 requires.

Related reading: Accessible Size and Fit Selectors: Swatches Are Radio Groups, Not Pictures, Accessible Gift Card Flows: Buying, Sending, and Redeeming Without a Trap, Accessible Quantity Pickers and Steppers on Product Pages.

Frequently asked questions

Does every form error need a suggestion?

No. WCAG 3.3.3 applies only when the site knows the correction or can determine it. A postcode that does not match the country, a card number with the wrong digit count, or a password that breaks a stated rule all have known fixes, and those must be offered. A genuinely ambiguous failure only needs clear error identification.

Is a red border enough to identify an error?

No. WCAG 3.3.1 requires errors to be identified in text, not by colour alone. A red outline plus the words card number is incomplete works; a red outline on its own does not, and it leaves screen reader users with no signal at all.

Where should the error message sit in the markup?

Next to the field, linked with aria-describedby, so a screen reader announces it when the field gets focus. On submit, move focus to an error summary at the top that lists each problem as a link jumping to the field.

Should a form trim spaces from discount codes?

Yes. A code with a trailing space is the same code, and rejecting it is the store's bug, not the shopper's. Trim whitespace before validating, and reserve the error message for codes that genuinely do not exist.