[AriaNotify] Scope proposal for V1 of API

[alisonmaher]

The current design of ariaNotify, as outlined in the spec PR, provides options for developers to specify the notification payload, as well as priority, interrupt and notificationId for a provided notification.

Due to current AT support and feedback from the Working Group, we have decided to scope the feature down to the core functionality of supplying the notification text, along with priority.

We still believe that interrupt and noticationId (or type) have strong use cases and we will continue to pursue these in parallel. The UIA team will be working on adding a 6th combination value to their notification API that will support the full combinations of interrupt and priority.

ATs have also provided feedback that they would like to support interrupt and think it is implementable, but do not have a current timeline. While we work with ATs to support the full functionality, we would like to provide authors with more ergonomic notification handling than is currently available with live regions in the meantime to gather feedback.

To support interrupt in the future, we would plan to also investigate adding a supports() related method (similar to https://developer.mozilla.org/en-US/docs/Web/API/ClipboardItem/supports_static) to provide authors a way to feature detect.

The notification type is also of interest to ATs, but no commitment to implementing support initially. In parallel, we hope to continue to work with Web Apps to determine a good initial list of notification types that would be recommended by the spec (or in some registry). We also would find it valuable for Web Apps to experiment with this sort of filtering functionality to help inform future development of type more broadly in the specification.

For the latest updates to V1 and future additions to the API, please take a look at the lates explainer updates.

Opening the issue to confirm with the group if there are any concerns with further scoping the API down as described in the explainer for V1.

[keithamus]

We won’t need a supports method for keys in an options bag, scripting can use getters to check whether or not the engine retrieved the value, and that can provide the necessary feature detection. supports() would be necessary for string values (eg the mimetype in the clipboard api) where the various values have no observable feature detection.