SCR32Sufficient technique WCAG 3.3.1 WCAG 3.3.3 Level A Human testing required

Put validation errors in the page as text

SCR32 is sufficient for identifying an error and advisory for suggesting a fix, the same split as SCR18, and the two are the two halves of one choice. SCR18 puts the message in a dialog. SCR32 puts it in the page. W3C's version is more specific than most people realize. The messages are anchor elements, placed above the fields they describe, whose href is an in-page link to the field that failed, so the summary and the jump are the same thing. Two of W3C's test steps go further than our habits do. The error messages have to receive focus, not merely exist, and the message has to disappear once the field is corrected. That second one is worth taking seriously, because a stale error sitting next to a field the user has already fixed is its own barrier. Tying each message to its input with aria-describedby is our recommendation rather than W3C's, and it is a good one, so do not cite this technique as the source for it.

How we find it in an audit

Reviewers break the form on purpose. Then they fix it and watch both directions. The failing submit has to produce text that names the field and says what is wrong. Focus has to land somewhere that reveals the problem, not at the top of the document. And the message has to go away once the value becomes valid. That last check is the one automation never runs and the one that catches the most real defects. A scanner can confirm text appeared next to an input. Whether the text is still true is a question only a person asks.

How affected users experience it

A red border says nothing to a screen reader and less to anyone who has never learned that red means broken. Without text, the form fails silently. The user guesses which of eleven fields it disliked. A summary at the top of the form is genuinely better than a per-field message on its own, because it can be reached in one jump and it says how many things went wrong. The best of both is what W3C describes here, a summary whose entries are links that put you directly in the field that needs work.

Passes vs. fails

Passes: the error names the fix. Fails: color is the only signal.

Passes

<div id="errors" tabindex="-1">
  <a href="#email">Email must look like name@example.com</a>
  <a href="#dob">Date of birth must be DD/MM/YYYY</a>
</div>
<!-- Focus moves to #errors. Each message is removed as its field is corrected. -->

Fails

<p class="error-count">2 errors found.</p>
<!-- Nothing names a field, nothing links anywhere, and every input still announces itself as fine. -->

How this gets tested

The W3C publishes test rules that define what a checker looks for here.

Error message describes invalid form field valueA tool finds candidates, you decide

Other ways to satisfy this rule

13 guides on this site are filed under 3.3.1 Error Identification. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.

This guide is our interpretation of W3C technique SCR32: Providing client-side validation and adding error text via the DOM. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.