WCAG 3.3.3 — Error Suggestion

Missing Error Suggestions

What is this issue?

Missing error suggestions occur when a form validation error is detected and described, but no guidance is provided on how to correct it. WCAG Success Criterion 3.3.3 (Level AA) requires that if an input error is automatically detected and suggestions for correction are known, the suggestions are provided to the user -- unless doing so would compromise security or the purpose of the content.

An error message that says "Invalid email address" satisfies WCAG 3.3.1 (Error Identification) but may fail 3.3.3 if a suggestion could be provided. A better message would be "Invalid email address. Did you mean user@gmail.com instead of user@gmial.com?" or "Please enter an email in the format name@example.com." The goal is to help users correct their mistakes rather than simply telling them they made one.

This criterion applies to all types of input validation: format errors (dates, phone numbers, emails), range errors (values outside allowed bounds), required field errors, and pattern-matching errors. For each, the suggestion should describe the expected format, provide an example, or offer a correction when one can be automatically determined.

Impact on users

Users with cognitive disabilities, learning disabilities, or limited digital literacy may not know how to correct an error from the error description alone. Saying "Invalid date" is useless if the user does not know the expected format. Saying "Enter date as MM/DD/YYYY, e.g., 04/15/2025" provides actionable guidance that any user can follow.

Screen reader users also benefit from suggestions because they may not be able to see placeholder text or nearby formatting hints that sighted users use as cues. An error suggestion that includes the expected format is self-contained and works without visual context.

For all users, error suggestions reduce form completion time and frustration. Research shows that forms with specific error suggestions have significantly lower abandonment rates than those with generic error messages. The marginal development effort to add suggestions pays for itself in improved conversion rates.

Code example

Before (non-compliant)

<!-- Unhelpful error messages -->
<p class="error">Invalid date.</p>
<p class="error">Password does not meet requirements.</p>
<p class="error">Invalid phone number.</p>
<p class="error">Email address is incorrect.</p>

After (compliant)

<!-- Helpful error suggestions -->
<p class="error" role="alert">
  Invalid date. Please enter a date in DD/MM/YYYY format,
  e.g., 15/04/2025.
</p>
<p class="error" role="alert">
  Password must be at least 8 characters and include
  one uppercase letter, one number, and one special character.
</p>
<p class="error" role="alert">
  Invalid phone number. Include area code,
  e.g., +1 (555) 123-4567.
</p>
<p class="error" role="alert">
  Email address is invalid. Did you mean
  user@gmail.com instead of user@gmial.com?
</p>

How Scrutia detects this issue

Scrutia analyzes error messages generated by form validation and evaluates whether they include actionable correction suggestions. It checks for format examples, expected value ranges, and auto-corrected alternatives. Error messages that only describe the problem without suggesting how to fix it are flagged with recommendations for adding specific suggestions.

Check your site for this issue

Scrutia audits your site against WCAG criteria in minutes.

Free audit

Frequently Asked Questions

When is it acceptable to not provide suggestions?

WCAG 3.3.3 includes an exception for security-sensitive content. For example, a login form should not suggest "Did you mean password123?" as this could compromise account security. But it can still suggest format requirements for new password creation.

Should I auto-correct user input?

Auto-correction can be helpful (e.g., fixing a common email typo), but always let the user confirm or reject the correction. WCAG 3.3.4 (Error Prevention) requires that users can review and correct submissions before they are finalized.

How specific should error suggestions be?

As specific as possible. "Invalid date" is poor. "Enter date as DD/MM/YYYY" is better. "Enter a date between 01/01/2020 and 31/12/2025 in DD/MM/YYYY format" is best. Include an example whenever possible.

Does your site have this issue?

Scrutia scans your pages against WCAG success criteria and delivers actionable fixes. Results in 5 minutes.

Run a free audit