You added aria-live="assertive". You set aria-invalid="true". You tested in Chrome with a mouse.
The error message works perfectly.
Then a JAWS user fills out your form and hears... nothing useful. Or worse,they hear the error, but by the time they navigate back to the field, the message is gone.
Two real cases from audits that show exactly where this breaks.
Case 1: The toast that disappeared before the user could act
An e-learning platform displayed validation errors as auto-dismissing toasts with data-delay="8000". Eight seconds sounds reasonable until you map what a screen reader user actually needs to do: hear the announcement, understand the error, navigate back to the field, correct it, re-submit. On a complex form, that's not enough time, and the message was gone before they could act.
WCAG failure: SC 2.2.1 — Timing Adjustable. Any time limit must be removable or adjustable. An 8-second toast carrying critical error information fails outright.
Fix: don't use auto-dismissing toasts for errors. Toasts work for redundant, low-stakes notifications. Not for information the user needs to act on. Display errors inline, adjacent to the field, and keep them visible until the user corrects the input.
Case 2: The error that vanished when focus left the field
A form showed the error while the field was focused, but an onblur listener hid the container the moment the user tabbed away. The screen reader announced only "invalid entry." No explanation, no guidance.
Two bugs in one component. First, the message disappeared on blur, so any user who tabbed to the next field and back found it gone. Second, there was no aria-describedby linking the error text to the input,so even when the message was visible, JAWS and NVDA had no reason to read it on focus.
With aria-describedby in place, JAWS, NVDA and VoiceOver all read the error automatically when the field receives focus. Remove the blur handler. Errors should persist until the user successfully corrects the field.
Both bugs come down to the same root cause: errors that aren't persistent and aren't programmatically connected to their field. Fix those two things and you cover the vast majority of screen reader failure modes on form validation.
What patterns are you using for error handling? Curious if anyone's hit edge cases with VoiceOver + Safari on iOS, that combination still has quirks worth discussing.
Top comments (0)