[AriaNotify] Should we first standardize live regions, and let ariaNotify can build on them?

[minorninth]

It feels like ariaNotify is trying to solve two problems simultaneously: poor ergonomics of live regions for web developers, and inconsistent implementations in browsers and screen readers.

Wouldn't it make more sense to address the inconsistent implementations first? I don't think this is unsolvable. We've had great success with specs such as ACCNAME and corresponding test suites that resolved ambiguities around name calculations and have led to very good consistency across browsers and screen readers. One thing I'd like to see is new native APIs that move the vast majority of the live region calculation into the browser rather than the current situation where the screen reader is forced to handle a lot of the logic and bookkeeping.

In addition, I'm not convinced that live regions are always the wrong API. No question, there are plenty of cases where ariaNotify would be more convenient, but not all of them. Sometimes live regions really are a good fit, when a notification is visual, or when the text of a status bar occasionally changes.

If we standardized live regions, we could implement ariaNotify as a polyfill and expect it to work well on all platforms. Any new features that ariaNotify needs ought to be added to live regions too - not just for the polyfill, but because of good use cases for live regions. Native support for ariaNotify could be seamless.

If the argument is that this would take too long, and we could deliver ariaNotify sooner to save web developers pain, I think that's underestimating just how much work it will be to fully specify, standardize, and test all of the behavior of ariaNotify. I'd really hate to see us rush something out there to replace live regions only for developers to find the replacement is inconsistent and buggy too.