What I want to do with this feature

• Announce messages to screen reader users (ex. loading, loading complete messages in single page apps and async components, user feedback, notifications, etc)
• Potentially the ability to abort a notification (ex. like clearTimeout). If there is any delay between the time when ariaNotify is called and when the announcement happens, a consuming application may want to abort a notification if it's no longer relevant. For example, due to the user changing views in a single page application.

What I'm having to do in the meantime

• Managing a hidden live region on the page. It is an understatement to say that this has been an extremely frustrating thing to do, with all sorts of weirdness and inconsistency between browser+screen reader combinations. Lots of hackery to make this work.

Aria-live regions are fundamentally broken and we need a better system.

• Having to have the aria-live region on the page and registered in the accessibility tree before use, and only then announcing when the content in that live region changes does not align with modern web apps which redraw large sections of the DOM dynamically.
• Browsers do not handle multiple announcements from different aria-live regions happening in close proximity. They may only announce the last one (or cut off other messages) which is inadequate accessibility.
• For this reason, I can only have one aria-live region on any given page - usually some kind of app-wide announcer component. I need to manually queue messages and re-start an announcement if new messages come in while existing messages are in the process of announcing. This may announce some things twice, but that's better than not at all. I shouldn't have to build such a custom solution.

I need an API that allows me to reliably send strings to live announce from different parts of the code and not have them step on each other or require extra invisible DOM elements to function.

To add to that:

For this reason, I can only have one aria-live region on any given page - usually some kind of app-wide announcer component.

It is also necessary to eventually remove these messages from the DOM because screen reader users can eventually find them using the virtual cursor. This presents another accessibility problem because these messages can be confusing when discovered out-of-context. However purging such messages is challenging because we don't really know when they've actually been announced.

I need to manually queue messages and re-start an announcement if new messages come in while existing messages are in the process of announcing.

And we currently have no way to know if messages are in the process of being announced, or if they were announced at all. Sometimes messages can be dropped due to other announcements.