3.3.3 Error Suggestion
- Level AA
- Understandable
- Since WCAG 2.0
Summary
Telling someone they got it wrong is not the same as telling them how to get it right. This criterion protects people with cognitive disabilities, people with low vision who cannot easily re-inspect what they typed, and screen reader users who cannot scan the form for visual hints, but in truth it protects everyone who has ever stared at "Invalid date" wondering what the system actually wanted. The rule is simple: when the system knows what would fix the error, it must say so. "Date must be in DD/MM/YYYY format" passes; "Invalid date" fails, because the validator that rejected the input plainly knew the expected format and withheld it.
The auditor's mental model has three steps. First, was the error automatically detected? If validation never fires, this criterion is not in play. Second, does the system know a correction, or at least the shape of one? Format rules, allowed ranges, required fields with known types, and near-miss values (a username one character off an existing one, a city name with a plausible spelling correction) all count as known suggestions. Third, does an exception apply? Security (login failures legitimately stay vague) and purpose (a quiz must not reveal the answer) are the only outs. If the answer to the first two is yes and no exception applies, a message that names the problem without pointing at the fix is a fail.
Official wording
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.
EN 301 549 mapping
- Web pages
- Clause 9.3.3.3
- Software and native apps
- Clause 11.3.3.3
Clauses 9.3.3.3 (web) and 11.3.3.3 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Test by breaking forms on purpose with plausible wrong input, then reading the message as if you had no idea what the field wanted. Enter a date as 2026-07-13 into a field expecting DD/MM/YYYY. Enter a quantity of 0 or 999 where the range is 1 to 10. Enter a phone number with spaces where the validator strips nothing. Submit a registration form with a username that is already taken. In each case, judge one thing: does the resulting message tell the user how to succeed on the next attempt, not merely that this attempt failed?
Look at every layer where validation happens. Inline client-side messages, messages injected after an AJAX round trip, and full-page server responses after submit all carry the same obligation. Native HTML validation bubbles (from required, pattern, min, max) usually provide serviceable suggestions for simple constraints, but the moment a site replaces them with custom validation, the custom message is what you grade. A custom validator that swaps the browser's "Please enter a number between 1 and 10" for a bare "Invalid value" has made things worse and fails.
Grade the message text, not its plumbing. Whether the suggestion is placed next to the field, listed in an error summary at the top, or both, it satisfies this criterion as long as it is provided as text the user can access. How the error is identified and associated with its field is SC 3.3.1 Error Identification territory; here you are only asking whether the content of the message contains the remedy.
Apply the exceptions narrowly. On a login form, "The username or password is incorrect" is correct practice, not a failure: confirming which half was wrong (revealing that the username exists) would jeopardise security. That allowance does not extend to the registration form on the same site, where "That username is already taken, try adding numbers" is both safe and required knowledge the system holds.
iOS
The same bar applies to native apps: under the European standard this requirement carries over to software unchanged, so an app form is graded exactly as a web form. There is no relaxed mobile version of the criterion.
Work through the app's data entry screens: sign-up, profile editing, payment details, address entry, date-of-birth fields, anything with a free-text field backed by validation. Enter plausible wrong input and trigger validation, then judge the resulting message. Watch specifically for the app patterns that fail: an alert that says only "Error" or "Something went wrong" after a form submit the app itself validated; a field border turning red with no text at all (that is a 3.3.1 problem first, but once any text appears, its content is graded here); a generic "Please check your entries" that names neither the field nor the fix.
Run VoiceOver during the test and confirm the suggestion text is reachable and read out; a suggestion rendered as an image or drawn in a custom view without an accessibility label is not provided to a screen reader user in any meaningful sense. Also credit good platform design: a date picker or segmented control that makes format errors impossible means there is often nothing to detect, and this criterion is simply not applicable to that field.
Android
The same requirement, unchanged for software under the European standard, applies to Android apps. Grade the message content to the same standard as web.
Trigger validation across the app's forms with plausible wrong input. The common Android delivery mechanisms are the error slot on a Material text field (TextInputLayout error text or its Compose equivalent), snackbars, toasts, and dialogs. All are acceptable carriers; the question is whether the text they carry contains the correction. "Postcode must be 5 digits" in a field's error slot passes. A toast reading "Invalid input" fails, and toasts have a second problem worth noting in your evidence: they vanish on a timer, which compounds the harm for exactly the users this criterion protects.
Test with TalkBack running and confirm the suggestion is announced or discoverable when the user returns focus to the field. As on iOS, check the near-miss cases the backend knows about: a taken username on sign-up should come back with alternatives or at least "already taken", an out-of-range amount should come back with the allowed range, and a rejected password on account creation should state the unmet rule ("must contain at least one number"), which is safe because no existing credential is being probed.
Pass and fail examples
Passes:
- A date field rejects "13/25/2026" with "Date must be in DD/MM/YYYY format", naming the expected format the validator was checking against.
- A quantity field rejects 45 with "Enter a number between 1 and 10": the known range is the suggestion.
- A sign-up form rejects a taken username with "That username is unavailable. Try jsmith2 or j_smith": near-miss alternatives the system generated.
- A login form responds to a bad credential pair with "The username or password is incorrect", with no hint as to which: the security exception applies.
- An online exam rejects an empty answer box with "Enter an answer before continuing" but never hints at the answer itself: the purpose exception protects the assessment, not the mechanics.
Fails:
- "Invalid date" on a field that enforces a specific format: the validator knows the format and does not share it.
- "Error in form" at the top of a ten-field page after server-side validation that knows exactly which constraint failed and what it was.
- A custom email validator that replaces the browser's built-in message with a bare "Incorrect value".
- An app toast reading "Invalid input" after a payment amount outside the allowed range: the range is known and unstated.
- A password-creation field that rejects a new password with "Password not accepted" while the rules (length, character classes) sit unstated in the backend.
Not a fail under this criterion:
- An error that is never flagged at all: if the input error is not automatically detected, there is nothing to grade here, and undetected errors that matter belong under SC 3.3.1 Error Identification.
- A visible error message that a screen reader user is never moved to or told about: the suggestion text may be fine; the identification and programmatic association problem files under 3.3.1 (and announcement of dynamic errors under SC 4.1.3 Status Messages).
- Missing format instructions shown before the user types: labels, hints, and format examples up front are SC 3.3.2 Labels or Instructions, not this criterion.
- A vague login error: security exception, provided the vagueness genuinely serves security and is not just laziness extended to every form on the site.
Commonly confused with
- SC 3.3.1 Error Identification. The most common misfiling, because the two cascade on the same message. 3.3.1 asks whether the error is detected, identified, and described to the user (what is wrong, on which field); 3.3.3 asks whether the message goes further and says how to fix it. "Email address is invalid" can pass 3.3.1 and fail 3.3.3 in the same breath. File one finding per criterion and keep the evidence distinct.
- SC 3.3.2 Labels or Instructions. 3.3.2 is about guidance before input: labels, required markers, format hints shown up front. 3.3.3 is about guidance after failure. A form can pass 3.3.2 with a lovely "DD/MM/YYYY" hint and still fail 3.3.3 when its error message says only "Invalid date", and vice versa.
- SC 3.3.4 Error Prevention (Legal, Financial, Data). 3.3.4 requires reversal, checking, or confirmation for consequential submissions so serious mistakes do not commit at all. 3.3.3 is about helping the user out of an ordinary detected error. A checkout with no confirmation step is a 3.3.4 finding even if every field-level error message is exemplary.
- SC 4.1.3 Status Messages. Whether a dynamically injected error is announced to assistive technology without moving focus is a status-message question. 3.3.3 only grades what the message says once the user can access it.
How AUDITSU tests this
AUDITSU's audit walkthrough covers error handling wherever a screen accepts input. For each form screen, the walkthrough prompts you to trigger validation with plausible wrong input (wrong format, out-of-range value, taken username), capture the exact message text as evidence, and answer the criterion's question directly: does this message tell the user how to succeed, or only that they failed? Where a message names a problem the system clearly knows the fix for, you grade the fail against this criterion; where the message never identifies the error at all, the walkthrough routes the finding to 3.3.1 instead, so the two do not get conflated in your report.
The walkthrough runs the same questions on native app screens, with the screen reader running where relevant, and records a pass, fail, or not applicable result per screen with the evidence attached. Login screens are prompted separately so the security exception is applied deliberately rather than by habit.
For the full guided workflow, see the audit platform.