Errors have to be announced, not merely drawn

What it is

If an error is only drawn, a screen-reader user’s focus may still be elsewhere, and that red text does not exist for them. Announcing means that when the error enters the interface, assistive technology speaks the message without the user having to find the node. This entry is only about speaking. It is not about whether color is enough, whether timing interrupts typing, or how specific the sentence must be.

Why it happens

Sighted users catch a transient (it turns red, a bar appears). A screen reader travels by focus and linear browse; transients do not enter that channel by default. After submit, focus is still on the button, the error sits under a field or at the top, and unless it enters a live region or focus moves there, what is spoken is still the button—the failure never happened. Announcing sends the error in as a state change, and only then does the recovery flow start on this channel. Without that send, even a complete three-part message exists only on the visual layer.

Studying it

Walk a failed-submit task with a screen reader, comparing visual-only change, focus moved to the error, and a live-region announcement.

Independent variables: whether focus moves after the error appears, whether a status message is received by assistive technology. Dependent variables: whether the user knows a failure occurred, time to find the first error, whether they believe submit succeeded.

Sighted screen-reader users will “see” the error and miss the hearing problem. The main sample should be people who use a screen reader daily; do not write the error into the study instructions.

Where it stops holding

When focus already moves to the first invalid field and that field’s error is spoken as its name or description, an extra announcement can be skipped so two channels do not talk over each other. Silent, self-healing failures with no user-facing consequence should not be announced. One-shot success confirmations also travel as status messages, but they must not share urgency with errors, or success and failure sound equally loud.

Applying it

• On failed submit, either move focus to the first error and guarantee it is spoken, or send a summary as a status message; do at least one.
• Dynamically inserted error nodes must be receivable by assistive technology at the current focus, not only exist in a DOM the user has not walked.
• Walk the main failure path with a real screen reader; do not stop at an automated check that a marker exists.
• Verify with the screen off, listening only. After a failed submit, if the next utterance is still the button’s name or silence, the announcement did not happen.

Related

• Within the group: H3.11.2 Color-only error states are silent to AT · H3.11.3 Announcing too early interrupts the keystroke · H3.11.4 The announcement must name the field and the reason
• Adjacent: J5.12 Announcing dynamic content · H1.05 Error location and focus · E6.03 Inline validation
• Search terms: status message · screen reader error · live region