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?

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

[cookiecrook]

Should be considered seriously with initial release, but not necessarily required for v1 as long as we retain a roadmap forward for more-specific braille. v1 braille could be identical to the speech notification.

[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.

[douggeoffray]

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

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?

[cookiecrook]

IMO, this is a nice to have unless the Speech group has a recommended (and achievable) path forward. Useful but not required for consideration in v1.

[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.

[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" and if so:

1. What tag should be used if "label" 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).

[spectranaut]

Discussed briefly today: https://www.w3.org/2023/08/17-aria-minutes.html#t04

Decided more discussion was necessary.

[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]

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]

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]

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]

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?

[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?