[AriaNotify] Should notificationId be a non-localized string? Is notificationId needed at all?
alisonmaher opened this issue · 3 comments
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.
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?
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.
This issue was briefly discussed at TPAC, with relevant minutes quoted below:
jcraig: I put myself on the queue to discuss verbosity prefs. I suggested that in addition to the type, that there'd be a keyword list for different types of things?
aardrian: I suggested a keyword list?
jcraig: I think that's this, iCloud is one of those places that use one of these live regions. One of the things you couldn't check is what the user's preferences were. So if you're going through and hit a link, you don't know if the user wants the sound ear con
jcraig: It could be a platform specific things instead of using the web audio api. But in addition to that, jamie's question about how the notification api works
jcraig: if you have a different view open, it's not going to be chattering at you when you're in a different tab. Something I haven't understood,
With most of the ideas stemming around having a pre-set list of types to choose from.
Given there has been mixed feedback around this particular topic, @keithamus, @smockle, @douggeoffray and I will be gathering some more data from AT and end users to determine if this is something we should pursue, and if so, what format is most preferrable and what types we'd want to support.
If others have thoughts or ideas that might influence the data we gather, or would like to contribute, please let us know.