Level AA

When a validator already knows the expected format or the closed set of valid values, 3.3.3 (Level AA) requires that suggestion to appear in the error message -- unless exposing it would jeopardize security or the purpose of the content.

3.3.3 Error Suggestion

In Plain Language

3.3.3 Error Suggestion (Level AA) extends 3.3.1 Error Identification[1]. Once your form has detected an input error and identified the field to the user, 3.3.3 asks a second question: does the system already know what a valid answer would look like? If it does, the suggestion has to be shown.

The criterion carves out one exception: suggestions are not required when exposing them would jeopardize the security or purpose of the content. A password field does not suggest corrections. A vocabulary quiz does not reveal the answer. Everything else does.

Why It Matters

  • A field that rejects input with Invalid date leaves the user to guess the format. The mechanism failure is that the application knows the expected pattern (MM/DD/YYYY, ISO 8601, whatever the parser accepts) and chooses not to expose it in the error string.
  • Screen-reader users cannot scan neighbouring placeholder text or visual hints after a submit fails. If the suggestion is not in the live error message wired to the field via aria-describedby, it is not in their announcement path -- the field reads as invalid with no recovery route[1].
  • Users with cognitive and learning disabilities are the primary beneficiary the W3C calls out: the Understanding document specifically names difficulty interpreting bare error notices as the failure mode 3.3.3 exists to close[1].
  • Trial-and-error resubmission is a motor-accessibility tax. Each re-attempt is another round of typing, focus management, and error scanning for a user who may already be using switch access or voice control.

Examples

Do: Name the expected format when the parser rejects input

✔ Error message suggests the correct format

<label for="email">Email address</label>
<input id="email" type="email" value="john@"
  aria-invalid="true"
  aria-describedby="email-err">
<p id="email-err" role="alert">
  Please enter a complete email address,
  e.g. john@example.com
</p>
Don't: Surface the rejection without the computable fix

Invalid input

✘ Error says nothing about what the user should change

<!-- FAILS 3.3.3: parser knows the expected pattern
     but the error string withholds it -->
<label for="email">Email address</label>
<input id="email" type="email" value="john@">
<p class="error">Invalid input</p>
Do: Suggest the nearest match from a closed vocabulary

✔ Suggests the closest match from known values

<label for="state">State or territory</label>
<input id="state" type="text" value="Calif"
  aria-invalid="true"
  aria-describedby="state-err">
<p id="state-err" role="alert">
  Did you mean California (CA)?
  Enter a full state name or two-letter
  abbreviation.
</p>
Don't: Validate against a known set and withhold the match

Not a valid state

✘ System knows valid states but offers no suggestion

<!-- FAILS 3.3.3: the validator holds a closed
     list of states but the error string does
     not expose the nearest match -->
<label for="state">State or territory</label>
<input id="state" type="text" value="Calif">
<p class="error">Not a valid state</p>

How to Fix It

  1. Treat every validator as a source of suggestion text. If the parser can say why input was rejected (wrong format, out-of-range number, unknown enum value), it can produce a concrete suggestion. Route that reason into the error string instead of collapsing it to Invalid.
  2. Emit the expected pattern in plain language. Enter a date as MM/DD/YYYY, Phone numbers use 10 digits, no spaces, Postal code must be 5 digits. The pattern lives in the validator already -- surface it.
  3. Compute the nearest valid value when the domain is closed. For enums (states, countries, currencies, product SKUs) run a Levenshtein or prefix match against the authoritative list and propose the top result: Did you mean California (CA)?. The suggestion is "known" in the 3.3.3 sense as soon as the list is server-side.
  4. Wire the suggestion to the field with aria-describedby. 3.3.3 is about the suggestion existing; pairing it with aria-describedby is how assistive tech announces it alongside the label when focus lands on the input. Without the association, the suggestion exists only for sighted mouse users.
  5. Honour the security and purpose exception deliberately. Password fields, authentication forms, and assessment items are the exception, not the default. Do not suggest which half of a login failed. Do not confirm whether a username exists. Do not reveal the correct answer in a quiz. Everything else -- addresses, dates, emails, SKUs, dropdown mismatches -- has to carry a suggestion[1].
  6. Stack with 3.3.1. 3.3.1 (Level A) requires that the field be identified as in error and the error described in text[2]. 3.3.3 adds the corrective step. Ship both together -- a compliant 3.3.3 message is also a compliant 3.3.1 message, but not the other way round.

References

  1. [1] W3C (2023). Understanding Success Criterion 3.3.3: Error Suggestion. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html ↩ ↩ ↩ ↩
  2. [2] W3C (2023). Understanding Success Criterion 3.3.1: Error Identification. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html ↩