WCAG 3.3.3 — Error Suggestion

What this requires

If an input error is automatically detected and suggestions for correction are known, the suggestions are provided to the user, unless it would jeopardise the security or purpose of the content. The criterion is one notch above 3.3.1 — it requires not just identifying the error but also helping fix it.

How AI coding tools fail this

When asked to "validate the email field", AI tools generate "Email is required" or "Email is invalid" messages with no suggested correction even when one is obvious. A user who types "gmial.com" gets told "invalid email" rather than "did you mean gmail.com?".

The second pattern: required-field errors that just say "Required" without telling the user which value the field expects. The user doesn't know what to type.

The third: format errors that show the constraint after the failure ("Must be at least 8 characters") rather than ahead of time and after. The constraint is a suggestion in disguise; surface it before the user has to fail.

Passing examples

Suggest a likely correction when one is detectable:

import { suggestEmailDomain } from "@/lib/email-suggest";

const suggestion = suggestEmailDomain(value);

{errors.email && (
  <p id="email-error" className="text-destructive">
    {errors.email}
    {suggestion && (
      <>
        {" "}Did you mean{" "}
        <button
          type="button"
          onClick={() => setValue(suggestion)}
          className="text-link underline"
        >
          {suggestion}
        </button>
        ?
      </>
    )}
  </p>
)}

Surface format requirements before the error fires:

<label htmlFor="password">
  Password
  <span className="text-sm text-muted-foreground">
    {" "}(at least 8 characters)
  </span>
</label>
<input
  id="password"
  type="password"
  aria-describedby="password-help"
  required
  minLength={8}
/>
<p id="password-help" className="sr-only">
  Password must be at least 8 characters.
</p>

Edge cases

Security exception. Suggestions that would compromise security (password hints, partial password matches) are exempt.
Email domain typo suggestions (mailcheck, email-suggest) are cheap and well-tested. Wire them up.
Form data hints (postal code format, date format) are best shown as helper text adjacent to the field, before validation.
Server-side errors ("This username is taken") can suggest alternatives if the server can compute them ("acme123", "acme_co").
Don't auto-correct silently. Suggest, let the user accept.

How Jeikin handles this

The scanner flags validation messages that lack contextual suggestion candidates (especially on email and required-format fields). The dashboard records each finding and tracks the move to suggestion- aware messaging. The call about whether a suggestion is feasible per field is editorial.

References

W3C — Understanding 3.3.3 Error Suggestion (opens in new tab)