To understand how screen readers work — and to diagnose issues — you need to understand the screen reader speech queue.
But before we look at that queue, we need to look at the thing that enters it: the utterance.
What is an utterance?
An utterance is the unit of speech that screen readers prepare to output — sometimes a sentence, sometimes a phrase, sometimes only a token like a single character.
- Focus changes
- AXEvents from the browser
- Live regions
- User actions, such as reading commands
An utterance is not spoken immediately. It is added to the speech queue to be processed.
For this analogy, think of utterances as different types of vehicles:
- Alerts are like fire trucks with their sirens on — they take priority over everything.
- Focus events are like ambulances — urgent and usually get high priority.
- Live region updates are like delivery vans — some urgent, some less urgent.
- Name and value changes are like ordinary cars.
- Typing events (individual keystrokes) are like motor scooters.
What is the speech queue?
In this analogy, the speech queue is like a traffic intersection with two lanes:
- High-priority lane for alerts, focus events, and assertive live regions
- Low-priority lane for polite live regions, name/value changes, and typing
More importantly, the speech queue has a traffic inspector. This inspector checks every vehicle before letting it through.
The inspector may decide to:
- Speak it
- Delay it
- Merge it
- Interrupt something else
- Ignore it
Now that we know how the lanes and the inspector work, let’s see how each type of vehicle behaves when it enters the intersection.
Alerts (fire trucks with sirens on)
Example: a session timeout warning appears.
- Use the high-priority lane
- Always go first in the queue
Focus events (ambulances)
Example: the user tabs to a new button.
- Use the high-priority lane
- Go first unless a fire truck arrives
Assertive live region updates (urgent delivery vans)
Example: aria-live="assertive" announces a critical change.
- Use the high-priority lane
- Often spoken immediately
Polite live region updates (non-urgent delivery vans)
Example: aria-live="polite" announces a status message.
- Use the low-priority lane
- Wait until the road is clear
Name and value changes (ordinary cars)
Example: a checkbox changes from unchecked to checked.
- Use the low-priority lane
- Wait their turn
Typing events (motor scooters)
Example: a user types several letters quickly.
- Use the low-priority lane
- Scooters often arrive in a swarm when the user types quickly.
- The traffic inspector waves the whole swarm through rather than stopping to check each one.
- Only the last scooter is noticed and spoken (intentional debouncing)
Screen readers behave differently
Important: The traffic analogy in this article is only a teaching tool.
Real screen readers do not follow the same rules, and they do not handle speech output in exactly the same way.
Each screen reader has:
- its own speech queue implementation
- its own priority system
- its own timing logic
- its own internal heuristics and strategies
Because of this, the same utterance may be:
- spoken immediately in one screen reader
- delayed in another
- merged into a single announcement
- ignored entirely
This is expected, normal, and part of how each product is designed.
Why this queue matters for accessibility
Once you understand utterances and how they move through the speech queue, you can avoid misinterpreting screen reader behaviour.
You are much less likely to wonder why something is spoken immediately, spoken after a pause, merged with something else, or not spoken at all.
Stay safe in traffic!