How does a screen reader user learn about a change that does not move focus, such as a saved confirmation?
answer
- A reader, not a monitor
- No movement means no speech
- Three options, and they combine
- Interruption versus being missed
- Announcements are spoken once and gone
basics
~20 sNothing is announced unless the interface asks for it. Three choices: move focus to the change, announce it without moving focus, or leave a status the user must find. Interrupting cuts off speech; queueing risks being missed.
solid answer
~50 sA screen reader speaks what the user moves to. A change that appears somewhere else on the screen — a result count, a saved confirmation, an error summary — is silent by default, because nothing took the user there. You have three options. **Move focus to it**: guaranteed to be heard, but it yanks the user out of their place, so reserve it for changes that block what they were doing. **Announce it without moving focus**, through an announcement channel the interface declares in advance, either queued behind whatever is currently being spoken or interrupting it. **Leave it as a status** the user can navigate to, which never interrupts but is only found by someone who thinks to look. The real trade-off is interruption versus loss: an interrupting announcement destroys what the user was listening to, and a queued one can arrive too late or be discarded when the user moves on.
code
pseudocode · 8 linesa change happened and focus did not move:
does it block what the user is doing? -> move focus to it
must it be heard within a second or two? -> announce, interrupting
is it useful but not urgent? -> announce, waiting for current speech
is it state rather than news? -> report it on the control itself
in every branch: leave the message on the screen as readable textgo deeper
Know that a change happening elsewhere on the screen is silent by default, and that making it visually obvious does nothing for a screen reader user.
Lay out the three options — move focus, announce without moving focus, or leave a findable status — and explain the trade-off between interrupting the user's current speech and having the message missed altogether.
Show judgement about which changes earn an interruption, and insist that anything worth announcing also stays on screen as text. Diagnose 'the user did the same thing three times' as a missing-feedback defect rather than a labelling one.
Own the pattern rather than the instance: decide once how the product reports status, so that teams inherit a consistent, non-competing set of announcements instead of every screen inventing its own and shouting over the others.
## Why silence is the default A screen reader is fundamentally a **reader**, not a monitor. It speaks the thing the user has moved to. When part of a screen changes without the user going there — a counter updates, a confirmation appears, a validation summary is filled in — there is no movement, so by default there is no speech. A sighted user notices the change through peripheral vision; that channel simply does not exist here, and no amount of visual prominence substitutes for it. Making the confirmation bigger, greener or animated changes nothing. This is the single most common way an interface passes an automated review and is still unusable: everything is named, everything is reachable, and the user has no idea whether their action worked. ## The three ways to surface a change | Option | What the user gets | Cost | When it is right | |---|---|---|---| | Move focus to the change | Guaranteed to be heard, and they are now at it | Loses their place; disorienting if unexpected | The change blocks what they were doing, or demands action now | | Announce without moving focus | Heard, place preserved | May be cut off, delayed, or missed entirely | Informational: a result count, a save, a background completion | | Leave it as a findable status | No interruption at all | Only reaches a user who goes looking | Persistent state that is useful on demand, never urgent | These are not exclusive, and the strongest pattern combines them: announce the change **and** leave the message on screen as ordinary content, so a user who missed the announcement can still go and read it. ## Interrupt or wait Announcing without moving focus splits into two behaviours, and choosing between them is the judgement the question is really about. - **Interrupting** cuts off whatever is being spoken right now. It guarantees the message is heard promptly, and it destroys the sentence the user was in the middle of — which may have been the very thing they were trying to read. Over-used, it makes a screen impossible to read at all. - **Waiting** queues the message behind the current speech. It is polite and it is the right default, but it can arrive several seconds late, after the context has moved on, and it can be discarded entirely if the user keeps moving, because a new movement generally supersedes queued output. A workable rule: **interrupt only when the change invalidates what the user is currently doing** — a submission that failed, a session about to end, a destructive operation that completed. Everything else waits. And whichever you choose, the announcement channel has to exist before the change happens; a channel created at the same moment as the message it carries frequently carries nothing, on every platform. ## An announcement is not content The deepest point here, and the one candidates most often miss: **an announcement is transient**. It is spoken once and it is gone. It is not somewhere in the structure that the user can navigate back to, re-read, or check while filling in the next field. If the message matters, it must exist twice: once as something spoken, once as text that stays on the screen and can be reached by moving to it. This also settles a frequent argument about error messages. An error announced but not left on screen is worse than useless: the user knows something went wrong, cannot recover the detail, and has to trigger the failure again to hear it. ## What the standard requires Success criterion **4.1.3 Status Messages** covers exactly this case: a status message that is not given focus must still be programmatically determinable, so it can be conveyed to the user. It sits at level **AA**. Note what it does not say — it does not require an interruption, and it does not require every change to be announced. It requires that the mechanism exist for messages that report status. ## A worked example A museum audio-guide handset lets a visitor add a stop to a personal tour. Tapping "add" shows a confirmation strip that fades after four seconds, and the tour counter changes from 6 to 7. Both changes are silent, and 5 of the 27 items in the review backlog are variations of the same complaint: visitors added the same stop three or four times because they had no way to tell whether the first tap worked. The fix that shipped has three parts, and only the first is the announcement: 1. Announce the confirmation without moving focus, waiting rather than interrupting — the visitor is often mid-sentence in an exhibit description, and cutting that off to say "added" trades one problem for a worse one. 2. Keep the confirmation on screen rather than fading it, so it can be reached and re-read. 3. Fold the state into the control itself, so that moving back to the control reports whether the stop is already in the tour — which serves the visitor who missed the announcement entirely. Together those cover the three ways a user might find out: they hear it, they read it, or they check. Designing for only the first is what leaves the message missed.
- Why is moving focus to a new message not simply the safest option, given it is always heard?Because it takes the user somewhere they did not ask to go. They lose their position, any partially heard content, and often their sense of where they are in a form; on a long screen, getting back can cost more time than the message saved. It is the right call when the change makes continuing pointless — a failed submission, an expiring session — and the wrong one for anything merely informative.
- A message is announced but disappears from the screen after a few seconds. What is the problem?The message existed only as speech, and speech is heard once. A user who was interrupted, who had output discarded by their next movement, or who simply needs the detail again has no way to retrieve it — there is nothing in the structure to navigate back to. Anything that matters should be announced and left on screen, so it can be reached and re-read.
- How would you decide whether a change is urgent enough to interrupt?Ask whether continuing is still meaningful. If what the user is doing has been invalidated — the submission failed, the session is about to end, the item they were configuring no longer exists — interrupt, because the speech they lose is now worthless anyway. If they could act on the message a few seconds later with no loss, wait. Interruption budget is small; spend it where the alternative is wasted work.
It is the difference between a tap on the shoulder, a note left on the desk, and someone shouting over the conversation you are already having. Each is right sometimes and infuriating the rest of the time.
saying these in an interview costs you the question
- Assumes any visible change is announced automatically
- Makes the confirmation larger or brighter and calls it fixed
- Interrupts for every message because it is guaranteed to be heard
- Announces an error but removes it from the screen afterwards
- Moves focus to every new message regardless of urgency
- Thinks an announcement can be re-read like ordinary content