WCAG 3.3.3 Error Suggestion is a Level AA rule that says: when a form automatically detects an input error and the correct value is known, you must suggest how to fix it in text — not just flag that something is wrong. The only exception is when a suggestion would compromise security or the content’s purpose.

What WCAG 3.3.3 requires

The official W3C wording is precise: “If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content” (W3C Understanding 3.3.3).

Three conditions trigger the obligation. First, your form must automatically detect the error (validation runs). Second, a correct value or format must be knowable — you can constrain what a valid entry looks like. Third, the suggestion must not create a security hole. When all three hold, a vague “invalid entry” is a failure; you owe the user a usable hint.

WCAG defines an input error narrowly: either required information the user left out, or information the user entered that falls outside the required format or allowed values. Both situations are in scope, and W3C splits the sufficient techniques accordingly — Situation A for “a specific format is required” and Situation B for “a limited set of values is allowed.”

Who it affects

3.3.3 exists because identifying an error isn’t the same as recovering from one. As W3C puts it, people with cognitive limitations “may find it difficult to understand how to correct the errors,” and people with visual disabilities “may not be able to figure out exactly how to correct the error.” The result is the same: the form gets abandoned.

  • Cognitive and learning disabilities — A user who sees “Invalid date” may not deduce that the field wanted MM/DD/YYYY. A suggested format lets them finish.
  • Blind and low-vision users — Screen reader users (JAWS, NVDA, VoiceOver) can’t scan the page for a red highlight. They need the correction spoken to them, attached to the field.
  • Motor disabilities — Every failed guess means more typing and more re-submission. Concrete suggestions cut the number of attempts, which W3C explicitly lists as a benefit for users with motor impairments.

This is part of the Understandable principle in the POUR framework, and it sits one rung above its Level A sibling, 3.3.1 Error Identification, in the conformance ladder.

Concrete failures (and the fix)

Failure 1: “Invalid input” with no guidance

A checkout field rejects a credit-card expiry of 13/26 and shows only “Invalid.” The format is fully knowable, so this fails 3.3.3. The fix names the rule and shows a model value:

<label for="exp">Expiry date (MM/YY)</label>
<input id="exp" name="exp" aria-describedby="exp-err" aria-invalid="true">
<p id="exp-err" role="alert">
  Month must be 01–12. Enter the expiry as MM/YY, for example 09/27.
</p>

The aria-describedby link means the suggestion is announced when focus reaches the field; role="alert" makes it announced immediately on submit. This combines W3C technique G85 (text description of the format) with the ARIA error-association pattern from the ARIA labels and roles guide.

Failure 2: A value outside the allowed set

A “State” field rejects Calfornia with “Not found.” Because the allowed values are a known list, W3C technique G84 applies — describe the disallowed value and point to valid ones, or offer the likely match:

<p id="state-err" role="alert">
  "Calfornia" isn't a US state. Did you mean California?
  Choose from the 50 state abbreviations, e.g. CA, NY, TX.
</p>

This mirrors the W3C example for a month field where typing 12 prompts “Do you mean December?” — converting or matching the input to a known-valid value (technique G177, suggesting correction text).

Failure 3: Color or icon only

A required email field turns its border red and shows a small warning icon, but no text. Screen reader users get nothing, and the suggestion is unknowable. This fails 3.3.3 and 1.4.1 Use of Color. The fix is simply to add real text: “Enter an email address that includes an @ and a domain, like name@example.com.”

Where the exception applies

You do not have to suggest a correction when it would leak something sensitive. On a login form, “Wrong password — your password is ‘Spring2026!’” is obviously forbidden. But you must still surface the known rules a new password violates (“needs 12+ characters including a number”), because rules aren’t secrets. Account numbers and one-time codes follow the same logic: state the format, never reveal the value.

How to test for 3.3.3

You can audit a form in minutes, but only by interacting with it — automated scanners flag missing labels, not the quality of an error message.

  1. Trigger every error path. Submit each field empty, then with a wrong format and an out-of-range value. Watch what message appears.
  2. Read the message as instructions. Ask: does it tell the user what to do, or only that something is wrong? “Required” or “Invalid” alone is a fail; “Enter a 5-digit ZIP, e.g. 90210” passes.
  3. Test with a screen reader. With NVDA or VoiceOver, confirm the suggestion is announced and tied to the right field — not stranded in a visual-only tooltip. Check that aria-describedby or a role="alert" region carries it.
  4. Check the security exception is justified. If a field gives no suggestion, confirm there’s a real security reason — not just developer shorthand.

Because 3.3.3 is about meaning rather than markup, it’s a textbook case for manual over automated testing. For the full form picture, pair this with the accessible forms guide and 3.3.2 Labels or Instructions, which heads off many errors before they happen.

Why this matters legally

Forms are where money and access live — checkout, contact, booking, account creation — so they’re a favorite target in ADA web claims. Plaintiff firms run scanners across hundreds of sites, and broken form feedback is easy to document. UsableNet tracked 4,187 digital accessibility lawsuits in 2024, and notably found that over 1,000 were filed against businesses that already had an accessibility widget installed — proof that overlays don’t insulate you (UsableNet 2024 Year-End Report).

Courts and the DOJ point to WCAG 2.1 AA as the practical benchmark for an accessible site, and the DOJ’s 2024 Title II rule formally adopted WCAG 2.1 AA as the technical standard for state and local government sites (ADA.gov web guidance). Since 3.3.3 is a Level AA criterion, it’s squarely inside that benchmark. A form that traps a blind user at the error stage is exactly the kind of barrier a demand letter cites.

This is general information, not legal advice. For your situation, consult a qualified attorney about ADA Title III exposure.

Fixing it the right way

Good error suggestions can’t be bolted on, because they encode your business rules — which ZIP formats you accept, which states you ship to, what a valid order number looks like. An overlay widget has no way to author that; it can’t know that “Calfornia” should suggest “California.” That’s why Curbcut is deliberately anti-overlay: we write conformant validation and error messaging directly into your form code, by hand, the way manual remediation is supposed to work.

If you’d like to know which of your fields fail 3.3.3 today, run a free Curbcut scan — we’ll show you the failing messages and the exact text and code that fixes them. When you’re ready, our team ([EXPERT_NAME] and the [AGENCY_NAME] crew) remediates the whole form flow and can document it in a VPAT.