If you've ever built a toast notification or a form error summary and the screen reader just... stayed silent, you're not alone. It's one of the most common accessibility bugs, and it's almost never obvious from reading the markup.
The usual culprit: the live region gets created and filled with content in the same tick. Screen readers register a region, then watch for subsequent changes. If there's no "before" state to diff against, there's nothing to announce. The fix is to render an empty container up front and update its text later, in a separate update.
There's a second layer most devs miss entirely: the announcement queue. Polite messages wait behind whatever's currently speaking. Assertive messages interrupt immediately and clear the polite queue, which means a status update mid-read can get silently dropped the moment an error fires. You won't see this in the DOM, you only catch it by listening.
That's the part that's genuinely hard to test without firing up NVDA or VoiceOver every single time you tweak a message. I've been using LiveRegionLab to simulate the whole thing in the browser, paste HTML, trigger updates, and watch exactly what gets spoken, queued, or interrupted, plus static flags for the classic mistakes like a non-empty region on load.
I break down how the queue actually behaves and what to check for here: https://devencyclopedia.com/tools/liveregionlab
Top comments (0)