Announcing too early interrupts the keystroke

What it is

If validation decides “not yet legal” mid-keystroke and also sends that decision into a live region, the screen reader inserts an error sentence and cuts the key echo or the next word being assembled. Announcing too early interrupts input: not “never announce,” but do not speak before the person has given the field up. This entry is about timing. It is not about whether the sentence names the field.

Why it happens

Typing occupies the speech channel: echo of each character, spelling, candidate words. A live-region message seizes that channel, usually at higher priority than echo. An email that has not yet reached @ is spoken as “invalid format”; people stop to fix a string that is not finished, or they turn echo off to hear the error, and typing itself goes blind. Blur, submit, or an explicit “check” is the boundary at which the field is given up; announcement hangs on those boundaries. A field already in error may clear immediately as it is corrected—that announcement ends an interruption rather than starting one.

Studying it

On the same format field, compare per-key announcement, blur announcement, and submit announcement.

Independent variables: announcement timing relative to input, live-region politeness, whether clearance is announced immediately during correction. Dependent variables: time to finish the field, number of interruptions, times an unfinished string is rewritten, final error rate.

Screen-reader key-echo settings dominate the experience; record whether echo is on. Do not count “they turned echo off, so it was not annoying” as a success of the timing design.

Where it stops holding

Hints tied to every character (length count, password strength), if they must be live, should stay out of the assertive error channel: a ignoreable secondary status, or an update after a pause. “One attempt left” on an OTP is security, but still should not be spoken on every digit. Speech input already owns the channel; do not insert a validation sentence mid-recognition.

Applying it

• Bind error announcement to blur or submit, not to every keyup.
• When a shown error becomes valid, immediately speak “corrected” or remove the error text so the channel returns to typing.
• Do not use an assertive live region for format problems that have not been submitted.
• Verify with key echo on, typing an email halfway. If an error sentence is inserted into the speech, the timing is early.

Related

• Within the group: H3.11.1 Errors have to be announced, not merely drawn · H3.11.2 Color-only error states are silent to AT · H3.11.4 The announcement must name the field and the reason
• Adjacent: H1.04 Timing of live validation · J5.12 Announcing dynamic content · E6.03 Inline validation
• Search terms: announcement timing · live region politeness · interruptive validation