WCAG 3.3.3 Error Suggestion: What a Checkout Form Should Say When Validation Fails
A ZIP code field rejects “9021” with a red border and the word “Invalid.” A promo code field rejects a mistyped code with the same generic message. A state dropdown rejects “California” typed as free text instead of selected from the list. In every case, the form caught something wrong — but caught isn’t the same as helped. WCAG SC 3.3.1 Error Identification only requires that an error be described in text. A separate, Level AA criterion covers the step most forms skip entirely: when a correction is actually knowable, saying what it is.
Quick answer: WCAG SC 3.3.3 Error Suggestion (Level AA) requires that “if an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user” — with one named exception: “unless it would jeopardize the security or purpose of the content.” In practice, that means a ZIP code field should say it needs 5 digits, not just “invalid”; a state field should name the allowed values or the closest match; and a password field is explicitly exempt from suggesting what you might have meant to type. The criterion only applies when a correction is knowable — a server that genuinely can’t tell why a promo code failed has nothing to suggest, and 3.3.3 doesn’t ask it to guess.
This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for checkout-form validation and how to meet it, not whether a specific implementation carries legal risk.
Identification and suggestion are two different requirements
Our guide to form labels and error messages covers SC 3.3.1 Error Identification in depth: a field has to be identified as wrong, and the error has to exist as text, not just a color change. That’s necessary, but it stops at “this is wrong.” The Understanding doc for 3.3.3 is explicit about the gap it closes: “While Success Criterion 3.3.1 ensures that users are notified of errors… some users, like users with cognitive limitations, may not understand how to correct an error” even once told one exists. A sighted user with a clear head can often infer what a ZIP code field wants from a generic “invalid” message. Someone who can’t see the field’s surrounding context, or who has a cognitive or memory impairment, may not — and “failed form submissions often result in site abandonment,” per the same Intent section, precisely because of this gap.
So a field that says “Invalid ZIP code” passes 3.3.1 and fails 3.3.3. A field that says “ZIP code must be 5 digits” passes both.
The one exception: when a suggestion isn’t safe to give
The criterion’s text carves out exactly one case: “unless it would jeopardize the security or purpose of the content.” The clearest e-commerce example is a password field. If a password is rejected, 3.3.3 doesn’t ask you to suggest what the correct password might be — doing so would defeat the point of having one. Our guide to accessible payment forms covers the related but distinct requirement that a password field still needs clear, stated requirements up front (length, allowed characters) — that’s SC 3.3.2 Labels or Instructions, not 3.3.3. Stating a rule in advance is fine; guessing at someone’s secret after the fact is the thing the exception exists to block.
A gift card or promo code field sits closer to the line. Our guide to gift card and promo code fields covers identifying why a code failed (expired, already used, doesn’t apply to this cart) — real, safe, knowable 3.3.1 territory. A fuzzy “did you mean ABC124?” guess at a mistyped code is different: it risks helping someone brute-force a code they don’t have, close enough to the exception’s intent that the safer default is precisely identifying the failure reason, not guessing at the correct code.
Where this actually shows up on a checkout form
A specific data format, known in advance
Technique G85 covers fields where the required format is fixed and knowable — a ZIP code, a phone number, a card expiry date. Its own guidance: when input is rejected, the description should “provide the correct examples, describe proper formatting, or suggest similar valid values.” A field that just says “Invalid” has given no suggestion at all.
<label for="zip">ZIP code</label>
<input type="text" id="zip" aria-invalid="true" aria-describedby="zip-error">
<span id="zip-error" role="alert">
ZIP code must be 5 digits, like 94103.
</span>The same pattern covers phone numbers (“Phone number must be 10 digits, like 415-555-0100”) and card expiry (“Expiry must be MM/YY, like 08/27”). None of this requires guessing what the shopper meant — it requires stating the format the field was always going to need, the moment it becomes relevant.
A limited, known set of allowed values
Technique G84 covers a field that only accepts one of a fixed set of values, like a state or country field: “the text description should indicate this fact. It should include the list of values if possible, or suggest the allowed value that is most similar to the entered value” — and explicitly, “it is not sufficient simply to indicate that a field has an error by putting an asterisk on its label or turning the label red.”
A native <select> mostly isn’t a 3.3.3 problem to begin with, since the only values a shopper can choose are already the allowed ones. The gap shows up when a state or country field is built as free text and a shopper types “Calif.” instead of the exact string the backend expects — fix it by switching to a real <select>, or by suggesting the closest match if free text has to stay.
A correction that has to be guessed at, not just formatted
Technique G177 covers the harder case: fuzzy-matching a plausible correction when the right format exists but what the user typed doesn’t match it. Its own worked examples map onto checkout patterns almost without translation: a duration field that gets “6” alone responds “Did you mean: 6 days, 6 weeks, 6 months or 6 years?” — the same shape as a subscription-interval field taking a bare number; a misspelled city name gets a link to the likely intended city, “determined by comparing their original input to a database” — directly applicable to a shipping-address city field that doesn’t match a postal lookup; a search feature that detects a typo “automatically resubmits the search with the corrected spelling,” the same mechanism behind “Did you mean” product-search suggestions most stores already run for search, just not yet for checkout fields.
An email field with an obvious typo domain (“[email protected]”) fits the same pattern — a check against a short list of common domain typos, surfaced as “Did you mean [email protected]?” with a one-click accept. Unlike a password or promo-code guess, it doesn’t run into the security exception, since confirming an email typo reveals nothing secret.
When the correction needs more room than an inline message
Most checkout suggestions fit inline, next to the field, using the same role="alert" pattern from our error-identification guide. Technique ARIA18 covers the heavier option for when a suggestion needs more room than an inline span can hold — a modal role="alertdialog" that interrupts and requires a decision before the shopper continues, such as an unavailable delivery date with a one-click “use the next available date instead” option. That’s meaningfully higher-friction than an inline error and easy to overuse — reserve it for cases substantial enough to need a decision, not routine format errors an inline message already covers.
What a scanner catches here, and what needs a person
A direct check of axe-core’s own rule-descriptions.md turns up no rule tagged wcag333, and structurally there couldn’t be one. A scanner can approximate whether a suggestion was provided (is there text near the invalid field?). Whether it’s actually useful — “ZIP code must be 5 digits” instead of “Invalid,” a fuzzy-match that offers the right city — is a content-quality judgment only a person reading the real message can make. A field can be properly structured and associated and still fail 3.3.3 outright by saying nothing more than “This field is invalid.”
FAQ
Does 3.3.3 apply to every form field on a checkout page? Only where a correction is both automatically detected and actually knowable. A blank required field has a knowable fix (“this field is required”) covered by 3.3.1/3.3.2. A field where the system genuinely can’t determine what went wrong — a card declined by the issuer for an unspecified reason — has no suggestion to give, and 3.3.3 doesn’t require inventing one.
Is “Did you mean…?” always required for a typo? Only when a correction is knowable with reasonable confidence — a typo against a short, known list (U.S. states, common email domains) qualifies. A free-text field with no reference list to match against has nothing to suggest from.
Does the security exception cover more than passwords? Any case where suggesting a correction would help someone guess something they shouldn’t have — passwords, security questions, arguably promo/gift-card codes where fuzzy-matching could support brute-forcing a valid one. It doesn’t cover format or allowed-value hints for routine fields like ZIP codes or state names, where nothing sensitive is being protected.
Get your checkout forms checked by a person, not just a parser
Whether an error message exists is a quick manual or automated check. Whether it actually tells a shopper how to fix the problem — correctly, for the specific failure that occurred — takes someone reading the real text against the real failure cases. Quietramp’s audits pair an automated scan with a manual review that tests checkout forms field-by-field, not just for presence of an error state but for whether it’s actually useful. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.