Accessibility: aria-live and role used incorrectly

[patrickhlauke]

(I landed here because I noticed that the toasts in https://github.com/bitwarden/browser aren't announced by screen readers, and worked out they're using ngx-toastr)

Currently, toastr generates its toasts with role="alertdialog" or role="alert" and aria-live="polite". However, these toasts are injected "fully formed" into the page, meaning that in most cases, screen readers won't actually announce them. The way live regions work is that you first need to define an element as a live region, and only after the element is "seen" by the screen reader are changes then announced. If you just inject it with content already present, it won't announce anything (with a few exceptions/odd behaviours related to browser-internal timings).

See also the first note on (which I added to MDN ages ago) https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions

Note: Assistive technologies will announce dynamic changes in the content of a live region. Including an aria-live attribute or a specialized live region role (such as role="alert") on the element you want to announce changes to works as long as you add the attribute before the changes occur — either in the original markup, or dynamically using JavaScript.

The solution to this is to have aria-live not on the actual toast, but on the overlay container where the toasts are then injected.

Here's a recording using Chrome/NVDA (Firefox/NVDA, Chrome/JAWS, Firefox/JAWS all behaved similarly) running through https://ngx-toastr.vercel.app/

ngx-toastr-live-region-issue.mp4

Note how the standard "Open Toast", "No animation", and "Notyf" toasts simply aren't announced at all. The "Bootstrap5" and "Pink" ones do announce, but I suspect it's due to the timing of when their content is actually injected into the toast container.

To show how adding aria-live="polite" to the overlay container itself would solve this, I just brutally added the attribute using devtools. Note how the toasts now all announce consistently when they appear. Obviously, you then don't need the aria-live on the actual toasts themselves, but I couldn't hack it further in devtools just for this demo.

In addition, as toasts aren't really dialogs - dialogs would receive focus and require a user action, whereas toasts are intended to appear then disappear without stealing the user's focus. I'd recommend removing the role="alertdialog" that's being used in some cases. role="alert" is more appropriate.

(this issue supersedes #444 and #833)

[scttcper]

🎉 This issue has been resolved in version 14.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀