[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.

[pkra]

Related: #1216 and its PR #2116

[alisonmaher]

Wouldn't it make more sense to address the inconsistent implementations first? I don't think this is unsolvable.

Yes, this is something we are working with ATs on. Unfortunately, this hasn't been prioritized by ATs yet, and why we had to scope some of the ariaNotify API down for V1 to match what is supported by live regions. So, standardizing either will inherently standardize the other as it currently stands.

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.

This is something we considered, but @douggeoffray can likely speak a bit more on why we decided it made more sense for an AT to handle this logic.

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.

100% agree. We think there are still separate and worthwhile use cases for live regions. As such, ariaNotify isn't meant to replace live regions, but to provide a tool for authors in cases where they are currently creating hacks to send arbitrary notifications using hidden dummy nodes.
 

If we standardized live regions, we could implement ariaNotify as a polyfill and expect it to work well on all platforms.

We are currently falling back to live regions when there isn't platform support today, and that is what is being used in the polyfill from my understanding (CC @keithamus and @smockle who helped in writing the polyfill).

Any new features that ariaNotify needs ought to be added to live regions too

This is something I hadn't considered but is something we can discuss when the time comes to expand ariaNotify beyond the V1 scope mentioned above.

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.

Hopefully given the V1 scope mentioned above, this alleviates the concern mentioned in this point.