Accessibility Wiki

Invalid fields must expose their error message

Rule form-error-association · Forms · impact serious · Static + live

↩ Back to the rules index · WCAG cross-reference

Why it matters

Marking a field aria-invalid="true" tells AT that something is wrong but not WHAT — without an associated text message the screen-reader user hears "invalid" and has to guess the fix. The message must also actually be readable: an empty or hidden aria-errormessage target can never reach the user. (Dangling aria-errormessage ids are reported by aria-idref-integrity, not here.)

How to fix

Point aria-errormessage (or aria-describedby) at an element containing the error text, and keep that element non-empty and visible while the field is invalid.

Example

✕ Fails
<label for="e1">Email</label><input id="e1" type="email" aria-invalid="true">
✓ Passes
<label for="e2">Email</label><input id="e2" type="email" aria-invalid="true" aria-describedby="e2-err"><span id="e2-err">Enter a valid email address.</span>

Example

✕ Fails
<input type="email" aria-label="Email" aria-invalid="true" aria-errormessage="err1"><span id="err1"></span>
✓ Passes
<input type="email" aria-label="Email" aria-invalid="true" aria-errormessage="err2"><span id="err2" role="alert">Enter a valid email address.</span>

WCAG success criteria

3.3.1 Error Identification — Level A

When an input error is detected, the field in error must be identified and the error described to the user in text.

Understanding 3.3.1

Standards

This rule contributes to the following standards:

WCAG A EN 301 549 Section 508 Trusted Tester

Standard Criteria
Section 508 3.3.1
EN 301 549 9.3.3.1

References