[AriaNotify] Should notificationId be a non-localized string? Is notificationId needed at all?

[alisonmaher]

The current design of AriaNotify, as outlined in the spec PR and the explainer, includes a notificationId, which is a non-localized string that can be optionally used by an author to provide an AT with further context about the notification.

This property has been fairly controversial in discussions thus far, namely stemming from the fact that it is a non-localized without any sort of registry or documentation of common notification types authors could use. See discussions at #1958 (comment) and #1958 (comment).

Many of the points stem around concerns with how are non-localized strings can be scalable for large products given that each team may choose to do their own mappings. Also, how will smaller products be able to make use of the benefits of notificationId that are already recognized by an AT if there is no predefined list of IDs?

Many believe some sort of registry or documentation of known/suggested IDs would provide more value to authors when determining how to categorize a notification. However, if we make the options more strict, how do we determine the right set of types, where should they live, what is the process to add a new entry, and who will own it?

In cases where an author is misusing notifications (which are the cases most relevant for filtering), we may not be able to expect such authors to properly supply a notificationId, if at all.

We have also gathered feedback that perhaps the filtering and earcon capabilities possible with notificationId should be owned by web apps as opposed to ATs, whereas others feel strongly that users would benefit from custom scripts for global filtering across common scenarios. Others also feel that it could be a good use case for AI to determine the categorization of notifications for such purposes.

That is all to say that notificationId has fairly strong opinions on both sides around whether we should have some sort of registry of pre-set values, or a non-localized string, as well as strong opinions on whether or not notificationId should exist altogether.

My proposal going forward is to drop notificationId as part of the first version of the spec, and use this issue to work through what a registry would look like and gather use cases to help unblock potential for adding it in a future version of the spec.

[MarioBatusic]

I support fully your ideas:

• NotificationId is a bad, unclear identifier. Maybe let's try with notificationType.
• This feature further on is nonsensical without a common registry of values that could be implemented by the screen readers.

I have still a question: Is it planned to fully replace live regions with ariaNotify? What about clear content changes visible for all,
such as new chat entries? If ariaNotify should completely replace live regions, content authors had to double dynamic content as ariaNotify strings?

[alisonmaher]

Is it planned to fully replace live regions with ariaNotify? What about clear content changes visible for all,
such as new chat entries? If ariaNotify should completely replace live regions, content authors had to double dynamic content as ariaNotify strings?

Great question. We foresee live regions continuing to be valuable for dynamically changing content on the page, which is a use case that live regions already works well today. As such, ariaNotify is not meant to replace live regions, but it is meant to provide an additional tool for authors to better handle cases where they want to send a notification, but there is no dynamically changing content. Or if an author wants more control over the interuptability behavior than is exposed by live regions today.