ARIA Notification Proposal Discussion Points

[scottaohara]

Resolutions of discussions will be tracked in #1957

Accessibility (ARIA) Notification API proposal - google doc

[scottaohara]

Does the notification API need to support Braille-specific notifications rather than identical notifications for speech and visibly rendered text?

Would the notification API need to provide support for separate braille specific notification strings? What are people's thoughts on this being a v1 release feature or if this is maybe something that could be rolled out as part of future updates?

It does seem like it might be a good idea to support, particularly due to the introduction of aria-braillelabel
and aria-brailleroledescription coming in ARIA 1.3

[spectranaut]

This was discussed in today's ARIA working group meeting: https://www.w3.org/2023/06/29-aria-minutes#t05

[douggeoffray]

Braille is not considered a P0. Proposal is get out the speech only version and address Braille as a P1. A separate Braille string can be added to the API. I think it would be important to keep a single call with speech and braille instead of calling the API twice (or two separate APIs), once for speech and once for Braille in order to keep the 2 in sync when consumed.

[cookiecrook]

PS. I updated the original title b/c it seemed (initially to me and more recently to others) that "does it need to support braille" meant "at all" rather than braille-unique strings in addition to the speech and/or hovertext/voicecontrol displayed text.

[cookiecrook]

FWIW, it seems like the majority of the Apple VoiceOver engineering team feels braille-specific strings could be implemented in the first release, aligned with the patterns defined for the aria-braille* attributes.

[alisonmaher]

This issue has been ported to #2334

[douggeoffray]

Does the notification API need to support speech markup/pronunciations (i.e. SSML or IPA)?

Would the notification API need to support speech markup within the specified string giving the author a way to specify how the string should be spoken (i.e. spelled out or explicit pronunciation such as should "a5" speak as "aye5" or "uh5", etc.)?

If this were added later, it would require a separate string as to not break the idea of simply sending the string untouched to the synth. It is also interesting that speech markup doesn't appear to be available in other aria tags (as far as I know) so why is it important here/now?

[spectranaut]

Discussed in today's ARIA working group meeting: https://www.w3.org/2023/07/20-aria-minutes.html#t05

[douggeoffray]

When the SSML markup was requested through the surveys, it was in the context of math. Likely math should be exposed through other means. SSML markup can be difficult to work with in context of other user verbosity settings as well as limitations on a given TTS engine being used. At this point the proposal is to consider SSML markup in the future as a P1.

If added, like Braille, a separate string would be required so the consumer is aware of the markup and not simply sending the string directly to the TTS engine where the markup may not be recognized properly.

[cookiecrook]

In hindsight, since a single text label string has so many applications:

• screen reader speech
• Voice control ("show labels")
• hover text / zoom text (re-render ax label in large text on hover/focus)
• braille (considered separately)

Maybe SSML or IPA is worth considering for v1.

[cookiecrook]

IOW, people will modify the original string to get the right pronunciation, while being unaware of the other downstream negative side effects.

[alisonmaher]

This discussion has been ported to #2335

[douggeoffray]

Guidance on fallback procedures (What to do if the platform/browser doesn't support the necessary API)

What guidance should be provided in the following cases:

1. Browser doesn't support ariaNotify
2. System platform doesn't support the necessary accessibility API
3. System platform support isn't rich enough for all ariaNotify functionality

[cookiecrook]

queryable support for the API should be considered... The engines should probably also not enable it by default until there is at least one major AT on the platform that supports it. Not useful to have a queryable API that indicates the browser pieces are in until the related SR pieces are also available. (Note: that this should NOT be gated on whether the AT is active... as that would leak user details)

[spectranaut]

Discussed in yesterday's meeting: https://www.w3.org/2023/07/27-aria-minutes#item05

[douggeoffray]

Explain / identify guidance for expected (not required) screen reader interaction

What specific examples/documentation should there be for expected screen reader interaction? For example:

• Need better examples
• Clean up poor examples such as the custom list box
• Should 1 component be able to clear notification from another?
• How do ariaNotify messages get blended with system notifications?

[spectranaut]

Discussed in today's meeting: https://www.w3.org/2023/08/03-aria-minutes#t05

[douggeoffray]

Referencing Arrays in the current spec appears confusing

Is the concept of "arrays" necessary or is the main point to emphasize the owning element of the notifications (document or any specific DOM element). The point is the user can control elements from the owning element without effecting other elements.

The thinking is the browser will immediately dispatch the ariaNotify data to the application's accessibility API. Because of this, there is little for the browser itself to do. What is the best way to convey this in the notification spec?

[jnurthen]

Discussed at https://www.w3.org/2023/08/10-aria-minutes.html#t06

[douggeoffray]

Does the notification API need to support "labels" or "types" and if so:

1. What tag should be used if "label" or "type" itself is not a good name?
2. What, if anything needs to be done for what can/should be used for the "label" (non-localized) named?

Note, Windows UIA Notification event uses the name "activityId" which is used as a namespace which is not localized giving the AT context (without parsing the localized string).

[cookiecrook]

One clarification from re-reviewing the minutes of that discussion is that "labels" may be a misnomer, this is clarifying text about the notification, so possibly "type" or another name would be better. (Changing discussion title from "labels" to "labels or types")

[cookiecrook]

Not sure I understand the "non-localized" comment above. Is this a machine-readable "type" or "key" rather than a user-presented string?

[cookiecrook]

One common "type" that was mentioned in discussion today is percentage based status updates... VoiceOver has the ability, based on user preference, to render percentages as a tone, rather than a numeric percentage, but some of the misuses of Live Regions today send chatty notifications ("13%, 14%, 15%") to screen readers rather than using a more appropriate control like a progress bar. How could "labels", "types", (or another aspect of the API) provide both and user control and authoring flexibility that is less likely to be misused than Live Regions are today?

[alisonmaher]

New issue has been opened for naming of notificationId at #2329

[alisonmaher]

New issue opened to discuss if this should be non-localized at #2330

[douggeoffray]

does the notification API need to be simpler?

Are there too many options? Is it being too overloaded? Should it be broken down?

[scottaohara]

not answering the question directly, but imo if the MVP can allow people to easily do the following, then anything else beyond that might be 'extra' (not to say those features wouldn't be welcome. i'm just looking at what should this potentially do as a baseline)

• allow authors to define a string to produce as a dynamic announcement
• allow authors to identify the priority / significance of the announcement (even sticking with polite/assertive in lieu of more discussion)
• recommend AT produce a notification log so that past messages can be reviewed. (the spec probably can't state that AT must do this. but a should would be nice)

those are the important bits that, imo, many people will want to do with this API. More can and should be done with it (one example to follow) - but if it just did those 3 things and did them consistently / well - then we'd have a really strong base to build from.

edit: this should not be part of the mvp list - as that is scope creep :)

as another idea, beyond the mvp, it'd be nice to allow authors to identify an element (e.g., via its ID) to pair with a message. E.g., maybe instead of announcing a full message a string like "notification available" is made. And if an ID for an element in the page provided, then AT could say "press [ key(s) ] to navigate to full message" ( i don't know if this idea has been discussed yet. if it was, i have no memory. sorry )

[aardrian]

Copying part of my #1958 (comment) since these discussion buckets came in while I was drafting it but before I posted, which might be why they have had no response.

7. Can you provide the survey questions / results?

[aleventhal]

Idea that's a bit more powerful than interruptCurrent and preventInterrupt.
Often times the vital part of a message is at the beginning.
It might be nice to be able to craft a message where the first part is uninterruptible, but the rest is interruptible.
I need a better example, but:

uninterruptibleText: "Date error. ",
interruptibleText: "Please enter a 4 digit year.",

The uninterruptibleText would be the general info and would be announced first.
It's not necessarily possible to do this as 2 separate notifications because there is no guarantee of one following the other immediately in the queue (or maybe we can work on that).

[douggeoffray]

This is an interesting thought. This does add more complexity and understanding from the web author to be able to break a single string down into two different parts (interruptible and non-interruptible).

To be clear, uninterruptible is still interruptible...each screen reader has done different things here. Today, JAWS/NVDA will still allow a focus or keypress to interrupt an assertive live region (which in my opinion makes it too easy to miss important messages). Assertive to them simply means interrupt speech and start speaking the assertive string. However, Narrator today will not allow an assertive message to be interrupted with a focus change or key press. Narrator requires the user to tap the control key to interrupt assertive messages. There should always be a way to silence assert/important strings but it should require a bit more work on the user's part.

Given Notification strings shouldn't be large content (like live regions), I would say this level of cutting up the string into two parts of interruptability levels isn't necessary.

[aleventhal]

Idea for handling potentially redundant notifications:

How about insertionMode: once.
This would indicate that only one of certain type of notification should ever be in the queue at the same time.
Might be a slight improvement over using "clear", in the "end of list" example given, because you don't have to clear other potentially useful notifications to avoid the redundant one.

[douggeoffray]

Based on the existing proposal, you can clear a queue based on a "label." If you did this, you wouldn't clear the potentially useful notifications. Doesn't this get the same thing?

[aleventhal]

Makes sense.

[aleventhal]

Re: "Bindings to User Activation"

I think we should put an example here.

[aleventhal]

Since each element has its own queue, is it possible the author will want to specify between clearing the element's queue and clearing all queues?

[douggeoffray]

Do we really believe that things would get this complicated with many queues on different elements all happening at the same time? If things get to that level, I would say notifications are being abused. Perhaps a better definition of when notifications should be used and, more importantly, when they shouldn't would be helpful and prevent something as complicated as you outlined.

[aardrian]

Is this the most recent / current discussion place? I missed the deep dive owing to a conflict and have some broad questions (and some of the above commentary may also be mooted by the deep dive so not sure if I read that as well).

[alisonmaher]

Yes, this is still a good place to add questions/discussion topics for ariaNotify - thanks for checking!

We are working with the chairs to figure out how best to share out the resources from the deep dive with those who weren't able to make it, so we'll follow up on that again this week to share out. We'll also check with them to see if we should potentially do another deep dive at some point since there are more discussion topics to work through on the API and path forward.

[douggeoffray]

notificationId: discussion points

notificationId is designed to be a stable API created by web developers on a per-case basis for screen reader and screen reader addon developers.

1. Is this purpose adequately communicated in the documentation, and is it an approach that we foresee working in the context of the web ecosystem?
2. Is "notificationId" an appropriate name?
3. Is it appropriate this is defined as a non-localized string that the web author can choose?
4. Instead of a string, should this be from a predefined enum?
5. If this comes from an enum, what happens when someone has a case that doesn’t fit into one of the predefined enums?

[scottaohara]

initially i thought this would have been specific token values so there could be parity across websites. if each website can define their own notificationIDs though, i'm not sure how that'd work out in the end. It'd be rare for individual website developers to use this feature, since they generally don't talk to AT vendors. and even if there were certain website developers that did create these special notificationIds, without standardization we could see one website use "foo" and another website use "foo" - and then is the screen reader supposed to know which website its currently on to know the difference between what each "foo" is meant to represent?

if there is a case for web developers to need to define custom notificationIds, arguably that could be done with a prefix, thus also mitigating a desire to standardize 'foo' - but we can't because X websites already have implemented custom versions of 'foo', so now that name is off the table (similarly to why popover wasn't named popup - because enough websites were already using the popup custom attribute that if that attribute name became standardized, those websites would break.

[aardrian]

Copying my two questions about notificationID from below since these discussion buckets came in while I was drafting it but before I posted, which might be why they have had no response.

2. Can we discuss a different name for notificationID? Keeping "ID" feels like an unnecessary confusion risk when talking about arbitrary strings from the author when "ID" has specific meanings in the context of HTML / CSS / JS / ARIA.
3. At 21:43 in the demo, it sounded like notificationID was meant for earcons. At 27:02 Hans asked if there was a set list and Doug said this is up to the vendor to implement. I feel this could have more value if it pulled from a defined list of tokens that map to earcons. Can we explore that?

Unrelated to my questions, this also came up during the WG call today (minutes) and there was some agreement on the call that this might be better as a token list and that otherwise this was only useful for corporations that control the entire stack from platform, through browser, to AT.

[spectranaut]

Discussed briefly last week: https://www.w3.org/2024/06/20-aria-minutes#t09

[douggeoffray]

• notificationID name

This can certainly be renamed to something else if ID feel confusing. I welcome suggestions!

• Free for all or predefined with custom options

It should be noted that the string is simply to give the screen reader context of the notification. The screen reader user would then have control over what they wanted to do with this specific notification. Replacing or adding an earcon was simply an example of what could be done. It is up to the screen reader on the options offered to the user. For example, that could be replace or add an earcon, replace the string with something else, replace the braille with something else, squelch the speech, squelch the braille, etc.

There appears to be consensus a public set of strings which can be shared across common experiences is required. Where this public site would be or how it would be managed would need to be determined.

It is important that a developer can quickly create strings which are not currently defined. I feel if the developer had to work through a long process to get a new string approved, the author would just choose to not add a string at all.

Screen readers, or screen reader users, could have the choice of whether they want a change of the notification to be web domain specific or across all web pages. Meaning if two separate “foo” ids were used by two completely different interactions, the user could control each separately.

The goal of the id is to give the screen reader user options, but if the notifications are used optimally, it is most likely the user will simply consume the notifications as intended. Only if the notifications are not used optimally or not needed or needed but shortened, would a user even consider filter/adapting the notification. It is also assumed that not every page will be customized.

[alisonmaher]

Issue forked out into: #2330

[douggeoffray]

Scoping / Source

notifications can only affect other notifications within the same scope. The scope can also be used by a screen reader to bring the user to the "source" of the fired notification.

Should this scope be set by a shared DOM element, or by something else like a shared id string?

[aleventhal]

Hi @douggeoffray, we discussed this in the ARIA WG meeting and had questions.
Can you give us more context about the shared id string? That's different from the notification id, right? Where would come from, how would the api possibly look? Do you see any advantages over using the element which is naturally there?

[douggeoffray]

My original understanding of this was to just use the DOM element itself. I believe the id string was suggested by Sarah.

[douggeoffray]

I believe Sarah threw out the idea of using a shared id string that could be tagged to the notification instead of a DOM element. Her concern was the DOM element may no longer be valid by the time the notifications hits the screen reader.

One idea is simply use the source of the main document for all notifications. This wouldn’t allow the screen reader to route the user to the interesting point related to the notification but it would always be available.

It would be interesting to get some specific examples of where the DOM element would, or typically, would be removed after invoking an ariaNotify. If this were the case, I would think that wouldn’t be a good element to tie to.

[douggeoffray]

Interrupt & flushing

Currently important/assertive notifications cannot interrupt or flush polite notifications. Important notifications can only interrupt & flush other important notifications, and only polite notifications can interrupt & flush other polite notifications. Is this clear from the docs, and is this the behavior we want?

[aardrian]

Copying part of my #1958 (comment) since these discussion buckets came in while I was drafting it but before I posted, which might be why they have had no response.

4. Can Doug build a matrix to show how interrupt and priority interact and win in a fight? I don't expect authors to recognize that these are two distinct and parallel fights. It took me a bit to sort that out and Sarah's question at 28:55 (higher priority unable to interrupt a lower priority) was critical to understanding this, IMO.

[douggeoffray]

<style> </style>

One of the top user complaints is that when an assertive live region comes through, screen readers such as JAWS/NVDA will silence the currently speaking string and flush all pending text and then speak the text of the assertive message. This means information that was potentially important for the user, which was flushed, was lost. This would require the user had to potentially redo the last command in the hopes they could hear the text that previously got flushed. The goal of ariaNotify is to have screen readers not flush any other pending information but simply prioritize it with the existing unspoken text. However, it does allow the web author to have the screen reader flush other notifications of the same source, priority, and interrupt level.

The best matrix I can come up with is:

Priority	Interrupt	Currently speaking string	Queued text (pending text to be spoken)	New text queued location
Important	None	Untouched	Untouched	End of high priority queue
Important	All	Only silenced if speaking a string from an important / all of the same source as this new notification	All strings in high priority queue that are important / all of the same source as this new notification are flushed	End of high priority queue
Important	Pending	Untouched	All strings in high priority queue that are important / all of the same source as this new notification are flushed	End of high priority queue
None	None	Untouched	Untouched	End of low priority queue
None	All	Only silenced if speaking a string from an none / all of the same source as this new notification	All strings in low priority queue that are none / all of the same source as this new notification are flushed	End of low priority queue
None	pending	Untouched	All strings in low priority queue that are none / all of the same source as this new notification are flushed	End of low priority queue

 

This new approach no longer allows for notifications to interrupt information generated by other means or different notification types.

[cookiecrook]

@douggeoffray There's a bunch of hidden markup in your previous post. Is that irrelevant cruft from your mail app, or is there something that should be escaped to be visible? Asking b/c the <style> </style> text made it through.

[douggeoffray]

Yeah, I copied the content from Word and it carried over a ton of markup. I couldn't figure out how to clean it up and keep the table formatted.

[alisonmaher]

This issue has been forked out to #2331

[douggeoffray]

Understandability

Are the queuing and interrupt features understandable?
Are there any chances that could be made to the docs or API that would make this easier to use and less prone to misuse? E.g. would web developers find something like assertive: true/false be easier to understand than priority: ‘important’ | ‘none’, since it uses existing language? Or is this worse because it potentially makes a false equivalency?

[aardrian]

Copying part of my #1958 (comment) since these discussion buckets came in while I was drafting it but before I posted, which might be why they have had no response.

1. A significant frustration I hear from SR users is the inability to move back through announced live regions (other than using the speech history of their screen reader). Since this lets authors clip (versus flush) announcements, given users have learned clipped announcements often means missed announcements, will this include a method to go back in the buffer history?

[douggeoffray]

I’m not sure I’m understanding the question. However, it is completely up to the screen reader of what it offers their users. The screen reader has the choice of queuing up all the past x notifications and all parameters and original strings as well as what, if any, changes have been done on the notifications due to user settings based on the notificationIDs. This information can be presented to the user as a type of history review.

[douggeoffray]

IA2 support

Currently, on Windows, there is only support for UIA. There is no IA2 support.

1. Is it okay that only UIA is being used?
2. IA2 currently doesn't have direct support for notifications. Should something be added to IA2 or just simulate through existing live region approach?
3. Should both IA2 and UIA be fired?
4. Should only IA2 be fired for IA2 only browsers and only UIA on UIA browsers?

[aardrian]

Copying part of my #1958 (comment) since these discussion buckets came in while I was drafting it but before I posted, which might be why they have had no response.

5. Doug said Microsoft is only building this for UIA (47:00) to avoid double exposure with IA2. Can Doug explain how this (UIA and IA2 concurrently with live regions) is not an issue with live regions on Windows today?
6. As a follow-up, it is my understanding that Firefox does not support UIA. Is Microsoft planning to add UIA support to Firefox as part of this ariaNotify push?

[douggeoffray]

Windows screen readers today handle live regions one of two ways:

1. Use IA2 and setup their own event listeners on the element specified by the live region and any text changes on that region
2. Use UIA’s live region event and system alert event (role=alert)

Because each only pick one of the two paths, there is no possibility of double speech.

Today, all Windows screen readers support the UIA Notification event because that is required/necessary for desktop applications. The UIA Notification event has not been tied to web content, and in fact, has not been possible for web content to fire a UIA Notification event. ariaNotify now only calls the UIA Notification event. IA2 implementation will not see anything happen.

Regarding Firefox, I’ve spoken with Jamie (James Teh) on this. He stated that he is already working on a native UIA implementation for Firefox and is fairly far along. This would allow for an easy integration of ariaNotify. The GitHub team is also willing to implement ariaNotify within Firefox if necessary.

Jamie also stated that there is no equivalent to the UIA notification event in IA2 and it doesn’t make sense to add one at this point. So Windows screen readers can just listen for the UIA notification event and continue to use IA2 for everything else without problems.

[alisonmaher]

This issue has been ported to #2336

[aardrian]

I watched the Deep Dive and gathered some notes (still sorry I missed it). I am breaking them down by the reasoning behind the feature and then I have some questions.

Live Regions Today

These were statements that seemed to be justification for proposing ariaNotify:

• At 02:34 Doug cited a survey but the questions, results, and methodology linked in the slides is behind a Microsoft login so I cannot judge how this proposal addresses the findings.
• At 03:10 Doug asserts NVDA is not displaying live regions in Braille displays as a conscious decision ("because of the overuse/misuse"). There was an NVDA Braille display bug which was fixed in July 2023 (though there may be a new bug with showing alert message text that I have to confirm). That on its own would not warrant a new API.
• The same slide mentions inconsistent implementation among browsers and screen readers, which is true but does not tell us why vendors they made those decisions. That could be insightful. Especially since it's not clear how those differences require a new API.
• I understand developers want a "reliable and consistent accessibility experience for users," but this seems to be something over which to press UAs and SRs, not necessarily mint a new API.
• At 4:50, Doug raises frustration with how assertive live regions flush all remaining content in the buffer. Only be TalkBack and VoiceOver on macOS do that (from my testing at https://cdpn.io/pen/debug/rNQMXPY). See prior two bullets.
• I appreciate he pinged JAWS, NVDA, and Narrator, but I think insight from the VoiceOver team (for macOS, iOS, and iPadOS), and TalkBack should be included in the discovery phase.
• At 5:35, there is a suggestion for when/how to announce assertive content and restore remaining content. It's unclear to me how we need a new API to address this.

Broadly, ariaNotify feels like a developer experience (DX) affordance, not a user affordance. If it makes authors create better live regions, then I am for it (I kind of like the priority/interrupt model). However, if developers (and UAs/SRs) struggle with the current limited set of options (3 today versus 6 in this proposal), then I don't believe better UX is a guarantee based on this discovery information.

My Questions

1. A significant frustration I hear from SR users is the inability to move back through announced live regions (other than using the speech history of their screen reader). Since this lets authors clip (versus flush) announcements, given users have learned clipped announcements often means missed announcements, will this include a method to go back in the buffer history?
2. Can we discuss a different name for notificationID? Keeping "ID" feels like an unnecessary confusion risk when talking about arbitrary strings from the author when "ID" has specific meanings in the context of HTML / CSS / JS / ARIA.
3. At 21:43 in the demo, it sounded like notificationID was meant for earcons. At 27:02 Hans asked if there was a set list and Doug said this is up to the vendor to implement. I feel this could have more value if it pulled from a defined list of tokens that map to earcons. Can we explore that?
4. Can Doug build a matrix to show how interrupt and priority interact and win in a fight? I don't expect authors to recognize that these are two distinct and parallel fights. It took me a bit to sort that out and Sarah's question at 28:55 (higher priority unable to interrupt a lower priority) was critical to understanding this, IMO.
5. Doug said Microsoft is only building this for UIA (47:00) to avoid double exposure with IA2. Can Doug explain how this (UIA and IA2 concurrently with live regions) is not an issue with live regions on Windows today?
6. As a follow-up, it is my understanding that Firefox does not support UIA. Is Microsoft planning to add UIA support to Firefox as part of this ariaNotify push?
7. Can you provide the survey questions / results?

[douggeoffray]

thanks for integrating your questions within the discussion points above. Please let me know if anything was left out.

[cookiecrook]

Avoiding pestering/annoyance of notifications, either too many or too irrelevant

I understand many aspects of the ariaNotify proposal (types, notification IDs, element-scopes, priority, division of critical vs interruptible text) are intended to reduce the annoyance of live regions and allow some level of verbosity or relevance control, particularly in the scenarios where irresponsible misuse equates to the level of abuse.

However, I also see a primary goal of the API to be “simpler,” easier to use than Live Regions, etc, which could lead us (even with the best of intentions) to an even-more abusable API for speech and braille announcements.

What follows is a list of known severe misuse scenarios that have proven annoying to screen reader users, so annoying that Apple engineers have implemented VoiceOver prefs to shut off live region notifications entirely. We’d like to provide a path to give users incentives to enable some types of helpful notifications while also giving them sufficient control to disallow abusive misuse, but the live regions API is vague enough that it’s differentiate these unwanted notifications from genuinely useful notifications.

Examples of misuse/abuse of Live Regions that should be disincentivized with a new API

• live regions in advertising containers announcing irrelevant or unwanted content
• timers or progress indicators using polite or assertive notifications, rather than “off”
• extra chatty “log” containers, particularly that conflict with the primary content… For example, a social media live stream (Twitch, Instagram, etc) that displays excessive amounts of “likes” or comments, such that the main audio is trampled by live regions notifications

Specific examples:

• This Texas Monthly article misuses an assertive live region to count down an ad, making the webpage unusable.
• Numerous examples of custom audio and video players on the web have added role=status to the timecode element (0:42) which updates every second, making the video and other page content unusable.

Miscellaneous musings of how to address these and other misuse scenarios.

• Some ideas already mentioned in the ariaNotify discussion thread (types, notification IDs, element scoping, priority, division of critical vs interruptible text, etc.) would allow more granular control by the web engine or downstream AT
• “ignore ongoing notifications from [this labeled control] or [from the site altogether]” similar to social media site (Slack, etc) features for “mute notifications for this thread”
• Disallow some usage (perhaps disallowing simple notifications) fired on major elements (document, body, main?) without more clarifying information like a notification ID, type, or other scoping metadata.
• Require UAs to log errors, warnings, or debug messages to the browser console for certain excessive intervals.
• Some implementors may object entirely to extra error or warning logging, and specifics of these intervals would be arguable, so perhaps test the extreme cases and leave intermediate triggers as an implementation detail?
• As an extreme case, any quickly repeated notification without a proper timer role or percentage scope (less than 1s) could be considered an error, as most of the speech notifications would be trampled before completion.
• Perhaps also number of notifications within some time period (5 times within 20s?) could be considered a warning.
• Debug logging (including use-presented string) for all AT notifications (including Live Regions and the Web Speech API utterances), so excessive examples could be caught by QA for the site?
• User prompt (non-blocking) on first attempt (similar to privacy APIs for location API and default browser notifications) allowing user to allow or disallow AT notifications
• Is so, how much should be in the browser, and how much in the AT?
• If user has previously disallowed notifications (or live regions) at the system level, this could be a gentle way to alert them that “this site, which you use daily, might not be misusing live regions like those other sites that caused to to disable them outright.”

[alisonmaher]

@cookiecrook Given that this would also apply to live regions, as well, and not just ariaNotify, should we open a general issue to discuss/explore this more broadly. Not sure where such an issue should live, but I do really like your idea around having some sort of DevTools logging to bubble such cases up to authors.

[cookiecrook]

• [ariaNotify] avoid pestering/annoyance of notifications, either too many or too irrelevant #2499

[minorninth]

Should notifications be HTML rather than plaintext or SSML?

It feels like a missed opportunity to invent a new API that's built around plaintext, or a speech-only markup language like SSML. I'm fine with not prioritizing braille in v1 but I don't think we should build an API that's not rich enough to support rich notifications in the future.

Screen readers already don't just read the text of the web as plaintext, some screen readers support things like:

• Inline markup like bold/italic/emphasis
• Pronunciation hints (CSS speak-as)
• Different output for speech vs braille
• Math
• Abbreviations
• Various markup to distinguish between phone numbers vs math, etc.
• Switching languages in the middle of one sentence

More importantly, these are all web features (HTML, CSS, etc.) - and as they're added to web standards, browsers and screen readers can adopt them to provide richer speech and braille output.

Do we really want to move to an API that leaves out all of that potential? Do we want to say that we're never going to have an API that provides a way to annotate whether something is a phone number or an equation, or stresses one word - or that if we're ever going to support those that we'd have to reinvent them, rather than building on existing support for reading HTML?

[alisonmaher]

Thanks @minorninth for filing these issues. Would you mind opening separate issues in the Github repo for these (example #2331). We've recently moved a lot of the issues related to ariaNotify to their own issues to allow for better visibility and discussion with the group

[minorninth]

No problem: moved to #2478

[cookiecrook]

I'm fine with not prioritizing braille in v1

For clarity, the braille bit not prioritized in v1 is the braille-only alternative, similar label vs braillelabel. Braille in general should absolutely work in v1.

[cookiecrook]

HTML

Whether it’s HTML or not, I concur with the need for a structured payload in some format. Perhaps a DOM node, which could be a string node or element node containing other strings or elements.

What kind of limits should the “structured notification” payload have? E.g. would you expect to be able to pass a link or other interactive control in the notification payload?

[alisonmaher]

Thanks @cookiecrook for the replies. Do you mind posting to #2478, as well, which is where this thread got forked to?

[minorninth]

Should we first standardize live regions, and let ariaNotify can build on them?

It feels like ariaNotify is trying to solve two problems simultaneously: poor ergonomics of live regions for web developers, and inconsistent implementations in browsers and screen readers.

Wouldn't it make more sense to address the inconsistent implementations first? I don't think this is unsolvable. We've had great success with specs such as ACCNAME and corresponding test suites that resolved ambiguities around name calculations and have led to very good consistency across browsers and screen readers. One thing I'd like to see is new native APIs that move the vast majority of the live region calculation into the browser rather than the current situation where the screen reader is forced to handle a lot of the logic and bookkeeping.

In addition, I'm not convinced that live regions are always the wrong API. No question, there are plenty of cases where ariaNotify would be more convenient, but not all of them. Sometimes live regions really are a good fit, when a notification is visual, or when the text of a status bar occasionally changes.

If we standardized live regions, we could implement ariaNotify as a polyfill and expect it to work well on all platforms. Any new features that ariaNotify needs ought to be added to live regions too - not just for the polyfill, but because of good use cases for live regions. Native support for ariaNotify could be seamless.

If the argument is that this would take too long, and we could deliver ariaNotify sooner to save web developers pain, I think that's underestimating just how much work it will be to fully specify, standardize, and test all of the behavior of ariaNotify. I'd really hate to see us rush something out there to replace live regions only for developers to find the replacement is inconsistent and buggy too.

[minorninth]

Moved to #2479