[AriaNotify] How should the interrupt property work?

[alisonmaher]

The current design of AriaNotify, as outlined in the spec PR and the explainer, includes a property that allows authors more control over the verbosity of their notifications, called interrupt.

We have received feedback that interrupt is confusing with respect to how flushing works, and that it doesn't quite cover all use cases.

To help in outlining how interrupt works with its various value types (none, all, and pending) @douggeoffray put together a demo showcasing how each behaves in the case of a progress bar. The code for this demo can be found at https://codepen.io/douggeoffray/pen/WNqVQjO.

As demonstrated, this property will allow authors more customization of how noisy their notifications will be.

Currently, interrupt only flushes notifications of the same originating node and priority, if applicable. However, we received feedback that this doesn't cover all use cases desired by web authors, as outlined by the following example provided by @smhigley:

In an AI chat scenario, after sending a response we send a series of notifications as follows:

• Loading updates every 5 seconds (priority: none)
• Potentially a generating announcement once content streaming starts (and further updates every 5 seconds) (priority: none)
• When finished successfully, a notification including the full text content of the response (priority: important)
• When failed, an error message (priority: important)

This is currently in copilot chat controls, but the same pattern could be used elsewhere, anywhere content is loaded for a potentially long time, and can succeed or error.

Here is a code sample of the above use case: https://copilot-study.netlify.app/chatMay2024

As noted by this example, there is a desire to flush all notifications of the same node, regardless of priority, which isn't possible today with the current definition of interrupt.

As a result, I am proposing to update to the flushing behavior of interrupt as follows, with the change from the current proposal bolded:

1. Only flush items from the same node (as is specified today)
2. If priority is set to important, and interrupt is all, flush all notifications for that node, no matter the priority.
3. If priority is set to none, and interrupt is all, flush only the notifications with the same node and priority of none. This way, low priority items won't flush high priority items.
4. Points 2 and 3 would be the same for an interrupt value of pending, but only flush notifications that are pending as opposed to also those that are currently being spoken.