SCR18Sufficient technique WCAG 3.3.1 WCAG 3.3.3 WCAG 3.3.4 Level A Human testing required

Validate in the browser and describe the error

SCR18 is sufficient for identifying an error and only advisory for suggesting how to fix it, which is a distinction the badge above cannot draw for you. The mechanism is older than most people expect. SCR18 is the alert-dialog route, where a script checks the value and puts up a modal that describes the problem in words. W3C validates as values are entered, field by field, rather than waiting for the submit button. Once the user dismisses the dialog it is helpful, in W3C's word rather than ours, if focus lands on the field that failed. We would call that required and we would be going beyond the technique to say so. The in-page route is a different technique, SCR32, which puts the message in the document instead of in a dialog. Neither is better everywhere. Pick the one your interface can carry.

How we find it in an audit

Reviewers submit every form with deliberately wrong data, bad dates, malformed emails, empty required fields, and grade what comes back. A scanner can confirm a message appeared and can never judge whether it helps, which is the whole difficulty. "Invalid input" with no field name is a defect even though validation technically ran and technically said something. We look for three things in the text. The field, the problem, and what a correct value looks like.

How affected users experience it

A blind user presses submit, the page seems to do nothing, and no error reaches them. Or one does and it says "error" and stops. Either way the next move is to tab back through every field hunting for the broken one by trial and error, which on a fourteen-field application form is several minutes of guessing. A message that names the field and shows the format turns that into one correction. The difference is not politeness. It is whether the form can be finished at all.

Passes vs. fails

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

Passes

if (!validDate(start.value)) {
  alert("Start date must be DD/MM/YYYY. For example, 04/09/2026.");
  start.focus();
}

Fails

if (!validDate(input.value)) { form.reportValidity(); return false; }
// Blocks the submit. Says nothing about which field or why.

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 SCR18: Providing client-side validation and alert. 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.