Live Region Support

This post does not discuss whether live regions are good, nor is it a post about the best way to use them. This post only covers how they are exposed to the audience who experiences them — screen reader users. Written by a non-screen-reader user.

1970s movie poster of darkened baby carriage with two clawed and bloody hands reaching out while cops run in the far background, titled “It’s Alive!”. If you’re here because your live region isn’t working as you expect, then your expectation is wrong, you did something wrong, or you found a fun bug. Read Pat’s Why are my live regions not working? instead of this post.

If you want a quick review of current support and simple test cases with testing steps, then keep reading. Otherwise, I dunno, close this tab?

Demo

I made this demo in mid-2024 to demonstrate a problem. It now covers five kinds of live regions:

That last one is a bit of a curve ball because it isn’t a live region, but it can functionally behave like one. Many authors are unaware of this, and for those who are aware, many think it’s a bug. The example uses a button, text input, and select menu. The button fires on activation, the two fields on change. Give the live region time to clear before moving to the next control. When testing, be sure you are hearing the de facto live region and not that you moved focus to the subsequent control with a description.

The demo also shows how these live regions work when hidden using any of three methods:

As always, I have a debug view without the Codepen cruft so you can test more easily.

See the Pen Live Regions, Hidden and Not by Adrian Roselli (@aardrian) on CodePen.

Results

The detailed results that follow the table go into specific versions and browsers used. Failure for a screen reader to support a feature properly may be a function of the browser, not the screen reader (especially with dynamic descriptions). Other bits:

Current Support
Screen Reader / Browser polite, Audio polite, Braille assertive, Audio assertive, Braille alert Role, Audio alert Role, Braille alert Role, Audio “alert” alert Role, Braille “alert” <output>, Audio <output>, Braille aria-describedby, Audio aria-describedby, Braille Hidden Regions Hidden
NVDA / Firefox polite assertive polite assertive assertive yes polite assertive no no
JAWS / Chrome polite assertive polite assertive polite assertive no no polite assertive polite? assertive?
Narrator / Edge polite assertive polite assertive polite assertive no no polite assertive no no
VoiceOver macOS / Safari assertive assertive assertive assertive no no no no
Orca / Firefox polite polite polite no no
TalkBack / Chrome polite polite polite no polite no no
VoiceOver iDevice / Safari polite assertive assertive no polite no no

Detailed Results

For the read-all testing on macOS, I would activate it (Ctrl + Opt + A), then when a button had focus I would hit Enter. I could visually confirm the live region was populated and I had the Braille emulator running. NVDA’s read-all (Caps Lock + A) and JAWS’ read-all (Caps Lock + ↓) does not leave programmatic focus on controls while reading so the tactic does not work there.

I’m not a daily screen reader user and I used the Braille viewers built into each screen reader, so they may not reflect actual hardware exposure to users.

Wrap-up

This reflects support as noted for the latest releases in the Detailed Results section. If you find something amiss, leave a comment. It’s possible I got something wrong during transcription or testing. Or just, you know, life.

No comments? Be the first!

Leave a Comment or Response

  • The form doesn’t support Markdown.
  • This form allows limited HTML.
  • Allowed HTML elements are <a href>, <blockquote>, <code>, <del>, <em>, <ins>, <q>, <strong>, and maybe some others. WordPress is fickle and randomly blocks or allows some.
  • If you want to include HTML examples in your comment, then HTML encode them. E.g. <code>&lt;div&gt;</code> (you can copy and paste that chunk).