Assistive technology must announce the notice
Aliases: live region · screen reader error · status message
What it is
Red text beside a field is a new stimulus for anyone who can see the layout. For a screen reader or some magnifiers it is only a new node in the document, and it is not spoken unless something makes it so. Announcement means the validation result is treated as a status change and spoken at the moment it happens, not whenever the user happens to move a virtual cursor onto that line. Adjacency answers “which field.” Announcement answers “this just happened.” Both have to hold for inline validation to exist on a non-visual path. Writing the sentence under the box without sending it through a live channel means the mechanism is absent for assistive-technology users.
Why it happens
A screen reader follows focus and deliberate exploration, not pixel mutation. When validation fires on blur, focus has often already moved to the next field; the newly inserted error is not under the reading cursor, so the user keeps filling at the next label until submit is refused. If submit only scrolls visually to the error without moving focus or speaking, that scroll has no counterpart in the assistive path. Even a live region depends on politeness: too assertive, it interrupts the label currently being read; too polite, it waits until the user has already started typing. The field’s accessible name must also include the error state, or returning to the box yields only the original label, with no hint that the item is still wrong.
Where it stops holding
Per-keystroke validation produces a stream of announcements; saying “bad format” on every letter makes typing itself unusable—announce after a pause or on blur. Successful checks should not each say “correct,” or noise drowns the real errors. An exception is the moment a user has just repaired one error and needs a short confirmation before moving on. A live region bound to the whole form will, on a submit with ten errors, read an unusable paragraph; announce the count and put focus on the first error instead. If a product also plays its own spoken voice, keep only the assistive-technology channel—do not stack a second narrator.
Applying it
- Associate the error text with the field in the accessibility tree, and speak it on appearance via a live region or a focus move; color change alone is not enough.
- On a failed submit, move focus to the first invalid field so the reader starts from that name plus the error, rather than remaining on the submit button.
- Throttle announcements: speak on blur or submit, not on every key; after a repair, a short confirmation is useful, a cheer for every legal keystroke is not.
- Verify with keyboard and a screen reader on a deliberately invalid form. Hearing nothing, hearing an error but not finding the field, or being interrupted on every keystroke are all announcement failures.