3.3.3 Error Suggestion

Level: AA | Principle: Understandable | Since: WCAG 2.0 | Automation: Manual

What This Means

When a form input error is detected and suggestions for correction are known, the suggestions must be provided to the user — unless doing so would compromise security or the purpose of the content (such as a test or quiz). Simply saying "invalid input" is not enough; tell the user what valid input looks like.

Who This Affects

Cognitive disability users — they benefit the most from being told exactly how to fix an error instead of having to guess
Screen reader users — specific suggestions give them actionable information without having to explore the form to understand the expected format
Low literacy users — clear suggestions reduce the reading comprehension needed to complete the form
Everyone — helpful error suggestions reduce form abandonment and support requests

Common Pitfalls

1. Vague error messages with no suggestion

<!-- Bad: what format is expected? -->
<p class="error">Invalid date.</p>

<!-- Good: tells the user what to enter -->
<p class="error">Invalid date. Please use the format MM/DD/YYYY (e.g., 03/15/2026).</p>

2. Only restating the requirement without a suggestion

<!-- Bad: repeats the rule but doesn't show an example -->
<p class="error">Password does not meet requirements.</p>

<!-- Good: explains what's missing -->
<p class="error">
  Password must include at least one uppercase letter and one number.
  Example: Gandalf42
</p>

3. Not suggesting close matches for known-value fields

<!-- Bad: just says it's wrong -->
<label for="state">State</label>
<input id="state" type="text" value="Califronia">
<p class="error">Invalid state.</p>

<!-- Good: suggests the correct value -->
<label for="state">State</label>
<input id="state" type="text" value="Califronia" aria-invalid="true" aria-describedby="state-error">
<p id="state-error" class="error">
  "Califronia" is not a valid state. Did you mean "California"?
</p>

How to Fix

Provide format examples in error messages

<label for="phone">Phone number</label>
<input
  id="phone"
  type="tel"
  aria-invalid="true"
  aria-describedby="phone-error"
  value="555-1234"
>
<p id="phone-error" role="alert">
  Please enter a 10-digit phone number including area code (e.g., 555-867-5309).
</p>

Show what's missing for complex requirements

<label for="password">Password</label>
<input
  id="password"
  type="password"
  aria-invalid="true"
  aria-describedby="password-error"
>
<div id="password-error" role="alert">
  <p>Your password is missing:</p>
  <ul>
    <li>At least one uppercase letter</li>
    <li>At least one number</li>
  </ul>
</div>

Suggest corrections for constrained inputs

<label for="country">Country</label>
<input
  id="country"
  type="text"
  value="Untied States"
  aria-invalid="true"
  aria-describedby="country-error"
  list="countries"
>
<datalist id="countries">
  <option value="United States">
  <option value="United Kingdom">
  <option value="Canada">
</datalist>
<p id="country-error">
  "Untied States" was not recognized. Did you mean "United States"?
</p>

Exception: security-sensitive fields

<!-- It's acceptable to NOT suggest corrections for login errors -->
<p class="error">
  The username or password you entered is incorrect.
</p>
<!-- Do NOT say "The password is wrong" — that confirms the username exists -->

How to Test

Submit forms with various types of invalid data: wrong format (date, phone, email), misspelled values (state, country), and missing required patterns (password rules).
Read each error message and check if it includes a specific suggestion for how to fix the input (expected format, example, or corrected spelling).
For fields with known valid values (states, countries), verify the error suggests the closest match (e.g., "Did you mean California?").
For password fields, verify the error identifies exactly which requirements are not met.
Pass: Every error message includes a specific, actionable suggestion showing the user how to correct the input.
Fail: Any error message is vague (e.g., "Invalid input"), only restates the rule without an example, or does not suggest a correction when one is known.

axe-core Rules

This criterion cannot be reliably detected by automated tools. Error suggestion quality requires human judgment about whether the provided message is helpful and specific.