Do we need a notifications API in ARIA

[jnurthen]

To avoid having to do live region hacks.

Include @slauriat in these discussions due to Chromevox experience.

[schne324]

As someone who has resorted to live region hacks countless times (https://github.com/schne324/dragon-drop for example), this is a very interesting idea. @jnurthen did you have any high-level thoughts on what this API might look like?

[aleventhal]

It might be nice if the API could indicate:

• whether current announcements should be interrupted for the new announcement
• whether the new announcement should be interrupted for other speech

Something like:

waitForAllPreviousAnnouncements: boolean /* default false */
mustCompleteAnnouncement: boolean /* default false */

[slauriat]

This may get too far into mixing proposals, but it came to mind and I figured I would throw it out there: this could potentially reuse the existing live region behaviors and attributes and such, but add some attributes and behaviors as @aleventhal suggested, by expressing and manipulating the live region via the accessibility object model rather than in the DOM. That would also maintain support for richer expression through semantics within the contents, which you'd otherwise lose by going to something that takes a flat string, but without the DOM pollution of live regions used as a TTS API.

I don't have a good sense of how the browser-side mapping would work for that, though, in order to keep the advantage of the semantics without it ending up back in the navigable accessibility tree. Maybe something like a background page?

That idea wouldn't help the latency or reliability issues of in-DOM live regions, but - based on my experience - I don't think you'd need to or could go with a function call type API in order to solve those, respectively.

[cookiecrook]

This topic is going to be discussed in the ARIA deep-dive meeting at 9 AM Pacific Thursday June 4th. (Edit: June 11th, not June 4th.)

[cookiecrook]

@alice FYI only

[jnurthen]

No deep-dive next week. Will be June 11

[alice]

I think it's worth scoping out the use case for this more fully, before diving into API design.

For example:

• Is this purely for screen readers (cf. "live regions used as a TTS API")? If not, what is the intended behaviour for braille users, or indeed users of other ATs which have live updating via the accessibility tree?
• What specific cases currently require live region hacks? Why?

I don't doubt that there is a real need, given how often this request comes up, but it would be good to have a solid understanding of what the exact need is so that we can check the design against that.

[stes-acc]

It might be nice if the API could indicate:

• whether current announcements should be interrupted for the new announcement
• whether the new announcement should be interrupted for other speech

Something like:

waitForAllPreviousAnnouncements: boolean /* default false */
mustCompleteAnnouncement: boolean /* default false */

Queuing is VERY important BUT also existing live regions that may get updated in parallel must be considered in queuing algorithms.

[MelSumner]

I'll help @mcking65 work on this (idk about 1.3 but I do have some ideas). 👍

[cookiecrook]

Relating some older issues: AOM #84 and AOM #3.

Also @dlibby- and @travisleithead wrote up a new proposal at https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/ConfirmationOfAction/explainer.md

[scottaohara]

the Notification API for Confirmation of Action explainer is now published on wicg.github.io/aom

[jnurthen]

Adding to agenda to notify folks that the explainer (ariaNotify) seems to be progressing. Probably time we took a look at it.

[jnurthen]

Closing this based on the work going on in WICG