3.3.3 Error Suggestion

WCAG 2.2 · 3.3.3 AA Understandable

What it requires

When an input error is automatically detected and you know how to correct it, the suggestion for fixing it must be given to the user in text — unless doing so would jeopardise the security or purpose of the content (for example, a password or a quiz answer). This builds on 3.3.1 Error Identification: it is not enough to say a field is wrong, you should also tell the user what a valid value looks like.

For instance, if a date is out of range, suggest the nearest valid date; if an email is malformed, explain the expected format; if a required field is empty, say what to enter. The suggestion can be inline next to the field or in an error summary, as long as it is conveyed in text.

  • People with cognitive and learning disabilities — who may not infer the correct format from a bare "invalid" message.
  • Screen reader users — who rely on a precise text suggestion rather than visual hints like a red outline or example placeholder.
  • People with low vision — who may miss subtle cues and need the fix stated explicitly.
  • Everyone — clear, actionable error text reduces frustration and failed submissions for all users.

How to detect it

Manual and tool checks for Error Suggestion
Check How Pass looks like
Trigger each validation error Submit forms with empty, malformed, and out-of-range values. Each message names the field and suggests a valid value or format.
Screen reader NVDA / VoiceOver: confirm the suggestion text is announced, not just a colour change. The correction is read aloud as text.
Keyboard & zoom Reach errors by keyboard; view at 200% / 400% zoom. Suggestions remain visible and associated with their field.
Automated tools axe, WAVE, Lighthouse. Limited — tools cannot judge if wording suggests a fix; manual review required.
Security exception Check fields where a suggestion would leak secrets. Omitting the suggestion is acceptable for passwords, security answers, etc.

How to fix it

  1. For every validated field, decide what a valid value is and state it in the error message.
  2. Write actionable text: instead of "Invalid date", say "Enter a date on or after today, e.g. 2026-07-01".
  3. Associate the message with the field using aria-describedby and set aria-invalid="true" so assistive tech announces it.
  4. Surface suggestions both inline and, for long forms, in an error summary.
  5. Omit the suggestion only where it would compromise security or the test's purpose.
<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true"
       aria-describedby="email-err">
<p id="email-err" class="field-error">
  Enter an email in the format name@example.com.
</p>

Copy-paste tests

Automated coverage

There is no fully automated axe-core rule that verifies 3.3.3 Error Suggestion: tools can flag missing labels, but only a person can judge whether an error message actually suggests a correction. Treat this as a manual review, using the console check and steps below.

Run this in the browser console

error-suggestion-audit.js 
// Read-only: surface likely error messages for manual review.
const errs = [...document.querySelectorAll(
  '[role=alert], [aria-invalid=true], .field-error, .error, [class*="error"]'
)];
errs.forEach(el => el.style.outline = '2px solid magenta');
console.table(errs.map(el => ({
  text: (el.textContent || '').trim().slice(0, 120),
  suggests: /(try|enter|use|format|must|should|example|e\.g\.)/i.test(el.textContent || '')
})));
console.log('Found', errs.length, 'candidate error messages.');

What to check manually: for each flagged error, confirm the message names a concrete correction (e.g. the expected format or allowed values), not just "invalid"; and confirm the suggestion is correct and would not break security or essential constraints.