Error Identification Rate: Do Your Forms Tell People What Went Wrong

Submit a checkout or contact form with three deliberate mistakes and read what it tells you. On many sites the answer is a red border, a generic banner saying please check the form, and no indication at all of which fields failed or why. The user is left to hunt for their own error, field by field, like proofreading someone else's work.

That hunt is measurable, and it should be measured, because it converts directly into abandoned forms and support contacts. Error identification rate is the metric that catches it. No automated scan score surfaces it.

Define the metric against the criterion

WCAG 2.1 Criterion 3.3.1 requires that when an input error is automatically detected, the item in error is identified and the error is described to the user in text. The metric simply counts compliance in practice: trigger every error state a form can produce, and score each on three points: field identified, problem described in text, correction indicated where the format is not obvious.

Divide passing errors by total error states triggered. A form with twelve possible validation failures, of which seven identify and describe them properly, has an error identification rate of just over half. That number is more useful in a remediation meeting than any overall accessibility percentage, because it points at specific fields and specific messages.

Colour is a hint, not an identification

The most common failure is a red outline or an icon with no text, or text placed in a summary banner far from the field with no association to it. Colour alone also fails Criterion 1.4.1, and icon only messages fail screen reader users entirely. The error text needs to be programmatically associated with the field, with aria describedby or an equivalent, so assistive technology announces it when the user reaches or returns to the field.

Placement matters for sighted users too. An error described only at the top of a long form forces scrolling and memory work. Error text at the field, with a summary that links to each error for longer forms, serves both groups. Count a field as passing only if both sighted and non sighted users can find the description without guessing.

Suggestions are the next criterion, and the same test

Criterion 3.3.3 Error Suggestion asks for correction guidance where it is known: the expected format for a date, the requirement a password failed, the difference between a postcode that is malformed and one that is merely unrecognised. Forms that say invalid entry for all three are identifying the error in the thinnest possible way and withholding the suggestion that would let the user fix it.

Score suggestions separately within the same test run. Identification rate tells you users can find the problem. Suggestion coverage tells you whether they are given what they need to solve it. A form can score well on the first and badly on the second, and that split tells the development team exactly what kind of fix to write.

Put it in the release checklist

Error states are the least tested part of most forms because they require deliberately failing, field by field, which nobody does for fun before a release. A metric with a number attached changes that. Run the error identification test on your top forms, checkout, account creation, contact, quote request, quarterly and after any form change, and track the rate alongside scan scores.

Report it by form, not as a site average. A checkout form at full identification and a quote form at a third average out to a comfortable number that hides the form costing you leads. Metrics are supposed to make problems visible. Averaging them away is the opposite of the job.

Related reading

These earlier guides go deeper on connected questions: Keyboard Trap Rate: The Metric That Finds What Your Scan Score Hides, Alt Text Coverage Lies When Decorative Images Count as Covered, and Form Label Coverage: A Metric That Counts Labels and Misses Meaning.

Frequently asked questions

What is error identification rate?

It is the share of a form's error states that properly identify the field in error, describe the problem in text, and, in a related measure, suggest the correction. It is calculated by triggering every validation error a form can produce and scoring each one against those points.

Which WCAG criteria cover form error messages?

WCAG 2.1 Criterion 3.3.1 Error Identification requires the item in error to be identified and the error described in text. Criterion 3.3.3 Error Suggestion requires guidance on how to correct the error where that is known. Colour only or icon only error indication does not meet the identification requirement.

Why do automated accessibility scans miss form errors?

Scans generally test the page as loaded, not its validation states. They do not submit forms with deliberate mistakes and assess the resulting messages, their text, or their programmatic association with fields. Error identification therefore requires manual or scripted functional testing.

How often should error identification be tested?

Quarterly for high value forms and after any change to a form or its validation. Error messages are often edited by different teams for tone or length and lose their descriptive content in the process, so the rate drifts unless it is rechecked.