fkhadra / react-toastify

React notification made easy 🚀 !
https://fkhadra.github.io/react-toastify/introduction
MIT License
12.33k stars 676 forks source link

Screen readers do not reliably announce toasts with role="alert" #1122

Open byrdsd opened 3 weeks ago

byrdsd commented 3 weeks ago

Do you want to request a feature or report a bug? Bug

What is the current behavior? When rendering toasts with the default role="alert", certain browser/screen reader combinations will not announce the toast.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your CodeSandbox (https://codesandbox.io/s/new) example below: Run screen reader and click notify button. https://codesandbox.io/p/sandbox/toest-screenreader-bug-sntjzh

What is the expected behavior? Screen reader should announce toasts when the default role="alert" attribute is retained.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 18.2.74 Firefox 127.0b9 (64-bit) orca screen reader 42.0 Pop OS 22.04

It's worth noting that this issue is very dependent on browser and screen reader. For example, it works fine in Chrome with Orca, but not in Firefox with Orca. The root of the issue is a misconfiguration in how role="alert" is being used. From MDN:

As with all other live regions, alerts will only be announced when the content of the element with role="alert" is updated. Make sure that the element with the role is present in the page's markup first - this will "prime" the browser and screen reader to keep watching the element for changes. After this, any changes to the content will be announced. Do not try to dynamically add/generate an element with role="alert" that is already populated with the alert message you want announced - this generally does not lead to an announcement, as it is not a content change.

Again, some combinations work; it depends on how the browser has implemented live regions.

To ensure reliable support across technologies, the role should be set on an element that is present at page load, such as the main .Toastify element.

Currently the live region is created when a toast pops, which prevents some combinations of browser/screen reader from reading it.