Search topics
Alerts that cut off VoiceOver for routine updates
A planning app writes every notice, from "Sam opened this task" to "Connection lost", into one role="alert" region, so in VoiceOver each routine update cuts into whatever is being read, and in other screen readers the urgent one sounds like the rest.
<div id="notices" class="notices" role="alert"> The problem
VoiceOver users are cut off in the middle of what they are reading each time the app reports something routine, and in every screen reader the one urgent message sounds like all the others.
A team's planning app shows one task at a time: its title, its due date and a few lines on what to do. Across the top of the page runs a thin notice bar. When a teammate opens the same task, it says "Sam opened this task". When the due date moves, "Sam changed the due date to 14 May". When a comment arrives, "New comment from Alex". And if the connection drops, "Connection lost. Changes you make now won't be saved." The script writes every one of them into the same element, and that element has role="alert".
A VoiceOver user on an iPad is reading the task line by line. Partway through the first line, VoiceOver stops and says "Sam opened this task." They go back to the line and start again, and a few words in, "Sam changed the due date to 14 May." Then the comment. Each notice is short and harmless, and each one breaks off the sentence they were in. When the connection really does drop, the warning sounds exactly like the three notices before it.
A JAWS or Narrator user on a laptop hears something else: each line in full, then the notice that arrived during it. Nothing is cut off, but the alert role makes no difference either. "Connection lost" waits for the end of the line, as "Sam opened this task" did, and is read in the same voice.
role="alert" is an assertive live region. ARIA says updates to an assertive region have the highest priority and should be presented immediately, and it lets the screen reader drop messages that were waiting. That is what a message people must act on needs, and what a routine notice must not have. Success criterion 4.1.3 asks that status messages can be presented to people without receiving focus, and its Understanding page says the point is to do it "in a way that doesn't unnecessarily interrupt their work". It lists using role="alert" or aria-live="assertive" on content that is not important and time-sensitive among its failures, though no technique page for that failure has been written yet. "Sam opened this task" is neither important nor time-sensitive. Screen readers don't all do what the region asks. In the 2026 releases, VoiceOver on macOS and iPadOS cut in for assertive regions and alerts, and on macOS stopped reading. NVDA, tested in Firefox, cut in for role="alert" too, read the message with the word "alert", then read again what it had cut off. JAWS and Narrator read alerts as they read polite regions, once the sentence or line in progress had ended. The developer chose the alert role because it is the one that is sure to be heard, and nothing in the browser warns that it is also the one that interrupts.
The notices arrive whether or not the person did anything, so the more people work on the same tasks, the more often a VoiceOver user is interrupted. Most screen reader users on phones and tablets use VoiceOver: 70.6% of the mobile respondents in WebAIM's 2024 survey, against 9.7% who named it as their main screen reader on a computer. A sighted user glances at the bar, or ignores it, and keeps reading.
2 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision In VoiceOver, each routine notice stops the line being read, so the person goes back for it and is cut off again by the next notice. In JAWS and Narrator the notices wait for the line, and the one urgent message can't be told from the rest.
- Limited language, cognitive and learning abilities People who listen to pages with a screen reader because reading is hard for them lose the thread each time a sentence is broken off, and have to find their place again.
A scan finds the live region, sees it on the page from the start, and passes it: whether a message is urgent is a matter of meaning, and no rule can read that. The audit flags an empty role="alert" or aria-live="assertive" region that waits for messages outside a form or dialog, unless its id or class names it for errors, so that a person checks what goes into it, but it can't see the messages until the app sends them. AI assistants asked to make notifications accessible may put role="alert" on all of them, for the same reason the developer did. Only listening while the notices arrive shows the interruptions, and only in a screen reader that honours them.
Try it
Press Read next line, as a screen reader user presses the Down arrow, and listen as the notices arrive.
A notice arrives a moment into each line. The panel shows what the screen reader says; on the page, the words read so far are highlighted, and red marks what was never read. The reader starts out reading as VoiceOver does: which notices cut the line off? Then switch to JAWS and Narrator: can you still tell the urgent one?
Broken Can you fix this?
Write the launch email
The launch email goes out on Monday at 9:00, after the final proofread.
Keep it short, with one link to the new collection.
Ask Alex for the product photos before Friday.
Send the draft to the team for comments by Thursday.
Screen reader says:
(Press Read next line)
The fix
Send routine notices to a status region, and keep the alert region for messages that can't wait.
- 1Use role="status" for routine notices, so they wait their turn.
- 2Use role="alert" only for a message people must act on now.
- 3Render both regions empty with the page, and never move focus to a notice.
<div id="notices" class="notices" role="alert"></div><div class="notices"> <p id="notice-status" role="status"></p> <p id="notice-alert" role="alert"></p></div>Why this fix: Interrupt only for what can't wait
The region is on the page from the start, so every notice is announced, and every notice is announced as an alert. VoiceOver, and NVDA in Firefox, break off the sentence for "Sam opened this task" just as they do for "Connection lost", and in JAWS and Narrator the two sound the same.
Routine notices now go to the status region. role="status" is a polite live region: the screen reader finishes the line it is reading, then says "Sam opened this task." The one message that can't wait still goes to the alert region, so in VoiceOver and NVDA it still cuts in, and because it is now the only thing that ever does, it stands out. In JAWS and Narrator nothing changes in when the messages are read, so the warning's own words carry the urgency: "Connection lost" comes first, then what it means for the person's changes. Both regions are in the HTML, empty, from the start, and the notice bar looks exactly as it did. Each call site says which kind of message it sends, so the choice is made once, where the message is written.
Which messages are urgent. A message is urgent when the person is about to lose something or must act now: a lost connection, a save or payment that failed, a session about to end, an error that blocks what they are doing. Everything else is routine: saved, added, updated, someone joined, a new comment. When you are not sure, it is routine. If a message is urgent but nobody could act on it, ask whether it needs to be said at all.
The opposite mistake. An urgent message in a polite region waits until the screen reader has finished speaking, and may wait behind other notices. A warning that a session is about to end is the usual case. The warning, and the way to extend the session, are covered in session timeouts with no warning or way to extend.
The words carry the urgency. Since JAWS and Narrator read an alert as they read a status message, an urgent message has to sound urgent in words: say what happened in the first two or three words ("Connection lost", "Payment failed"), then what it means and what to do. Keep it on screen until it is no longer true, rather than letting it disappear with the next notice, so people who reach the bar later still find it.
Two regions, not one that switches. Keep a status region and an alert region side by side, rather than one region whose aria-live the script changes before each message. With two fixed regions, a message can never go out with the politeness that was set for the one before it.
Notices that come together. Writing into a region replaces what was there. A routine notice that arrives a moment after another can replace it before it is read, so when both matter, join them into one message ("Sam opened this task and changed the due date to 14 May") or keep the last few as lines in the bar. Several alerts at once are worse: ARIA lets the screen reader drop messages that were waiting when an assertive one arrives, so only the last may be heard. MDN warns that several alerts at once, and unnecessary alerts, create bad user experiences.
Notification and toast components. Many let you choose the role for each kind of message. Check what yours does by default, since some render every message as an alert. Map success and information messages to status, and only the errors that need action now to alert. How long a toast stays on screen is a separate question, covered in toasts that vanish before you can read or undo them.
Clear an alert when it is no longer true. When the connection comes back, empty the alert region and write "Back online" into the status region. A warning left in place is read again by anyone who moves through the bar later, and it still says their changes won't be saved.
Not fixes. Moving focus to the notice gets it read in every screen reader, but it takes people away from what they were reading, for every notice, which is worse than the interruption. Taking the notices out of the live region altogether stops the interruptions, but then "Connection lost" is never heard either. A region that is added to the page together with its message is often not announced at all: that failure is covered in status messages that are shown but never announced.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Verify the fix
4 checks, no mouse.
Test with: Screen reader, Keyboard
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the notification component, or the list of messages it sends, changes.
Limits
Live regions behave differently across screen readers and browsers, and from one version to the next: what this guide describes is how the releases current in 2026 behaved. Understanding 4.1.3 also notes that assistive technology may delay, suppress or transform status messages to suit its user's settings. Whether a message is urgent is a judgement about the product, which only its team can make. This guide covers notices that arrive while someone is reading. A message that is never announced is covered in status messages that are shown but never announced, a clock that announces every second in countdown timers that screen readers keep reading out, and dialogs that ask people to confirm in confirmation dialogs that don't read out their question. Letting people put off interruptions altogether, at Level AAA, is a topic of its own. Test with the screen readers your users use.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: status-messages (opens in a new tab)
- WCAG Technique ARIA22 (opens in a new tab)
- WCAG Technique ARIA19 (opens in a new tab)
- w3.org: wai-aria-1.2 (opens in a new tab)
- developer.mozilla.org: alert_role (opens in a new tab)
- developer.mozilla.org: aria-live (opens in a new tab)
- webaim.org: screenreadersurvey10 (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.