Accessibility: regression - desktop notifications are not dynamically announced by screen readers

[patrickhlauke]

Steps To Reproduce

1. Use a screen reader
2. Trigger a notification/toast (e.g. edit an item, then save)

Expected Result

The notification/toast should be dynamically announced by the screen reader.

Actual Result

The notification is not announced.

Screenshots or Videos

Video of desktop app (latest one in master branch at the current time) with NVDA running. Note that the notification/toast is not announced.

bitwarden-desktop-nvda.mp4

Additional Context

Is this a regression from #2566 ?

Also, x-ref #2509

Operating System

Windows

Operating System Version

10 Build 19044

Installation method

Other

Build Version

2022.8.2

[Larry-Sussman]

Adding a note here that toast notifications are being announced correctly on MacOS with the VoiceOver utility. On Windows with NVDA, the toast is being read after some other headings so it's not clear and doesn't provide the best UX.

[patrickhlauke]

Confirming that in macOS they're announced (but on Windows, the problem still persists).

Note that live regions are always quite flaky and dependent on specific timings - incidentally, I just saw that some recent change in Chrome/Windows now causes ngx-toastr (which I assume is what Bitwarden still uses?) to be double-announced ... scttcper/ngx-toastr#957 (so the opposite issue of this here, where it's not announced at all)

I'll see if I can review exactly what's happening (or not) in Bitwarden's use of ngx-toastr - I'm assuming it's now using the latest version of that component, correct? Is it using a custom toast container, and if so is it using aria-live="polite" as per https://github.com/scttcper/ngx-toastr#put-toasts-in-your-own-container ?

[patrickhlauke]

just having an initial look under the hood, and it seems that at first the overlay container with aria-live="polite" does not exist in the page's DOM itself. so it's generated and then populated. in general, this is a bad idea since the browser doesn't have enough time to "prime" the container to listen for changes and notify the AT. sometimes this works, sometimes it doesn't, and comes down to flaky internal timings of when the change happens exactly (if on the cusp of one "frame" or the next one). I suspect that this is also causing issues later on...if it doesn't properly "see" and prime the <div> in time, even subsequent content changes aren't then sent to AT.

just to show the flakyness, I actually managed to capture a time when it DID work.

Video recording on Windows with NVDA, showing at first how the toasts are not announced (and, with developer tools open, how the overlay-container is not present at first and dynamically injected only when the first toast needs to appear), and one example where, due to luck/timings, the toasts do announce correctly.

bitwarden-toast.mp4

the solution is likely that the overlay container needs to be present right from the start, and defined as a custom container https://github.com/scttcper/ngx-toastr#put-toasts-in-your-own-container

[patrickhlauke]

Noting that this is still an issue in the latest version