1 of 20

Improving Notification Handling with AriaNotify

Alison Maher / Microsoft Edge

(almaher@microsoft.com)

2 of 20

What is an AT?

AT = Assistive Technology
“Products, equipment, and systems that enhance learning, working, and daily living for persons with disabilities.”
Examples:

Screen readers (JAWs, NVDA, etc)
Braille displays
Voice driven ATs (Voice Access, Voice Control, etc)
Magnifier
High Contrast Mode
And many others

3 of 20

ATs and Notification Use Cases

Difficult to convey to blind or low vision users:

Confirmation of action (ex: “bold on”, “bold off”)
Current presence (ex: “John Doe entered the meeting”, “Present state set to do not disturb”)
Reactions (ex: Raised hands, applause or thumbs up reactions in video meetings)
Error messages
Etc

4 of 20

Available solutions: ARIA Live Regions

Set aria-live on an element that has dynamically changing content
Will notify the user when the content changes
Values

off - changes should not be announced
polite - important information for user, but not urgent
assertive - immediate attention required

Example:�<form name="signup" id="signup">� <p id="errors" aria-live="assertive"></p>� … <Other form elements> …�</form>

5 of 20

ARIA Live Regions Pain Points

Can only be used with dynamically changed content
Not author ergonomic for other types of notifications like confirmation of action

Authors mimic dynamic updates offscreen to accomplish these notifications today
This means this text can be separately discoverable by screen reader users with their virtual cursor
Site-wide live region systems often manage and insert live regions in a specific area of the DOM (often at the end), which can fail when users open a modal dialog.

Live regions are inconsistently implemented
Live regions lack richness (no context and primitive prioritization)

Although live regions are capable of providing AT users with more information, there are some pain points that come along with this API.

For starters, live regions can only be used with dynamically changing content. As such, it is not ergonomic for other kinds of notifications like confirmation of action, where there is no dynamically changing content associated with the message the author would like to have announced.

Today, authors mimic dynamically changing content through offscreen content or hidden nodes to accomplish these sorts of notifications today, which can sometimes lead to unexpected side effects. Site-wide live region systems also often manage and insert live regions in a specific area of the DOM (often at the end), which can fail when users open a modal dialog.

Another complaint we have heard from users and authors is that live regions are inconsistently implemented across ATs, and that they lack context and richness beyond primitive prioritization types.

6 of 20

7 of 20

Solution Goals

Improve end user experience that is consistent and predictable, where users have more control over how they consume notifications
Empower screen readers developers by providing clear expectations and context
Empower web developers with improved notification handling ergonomics that is consistent and allows for more fine-tuning that improves end user experiences

8 of 20

Solution: ariaNotify

Explainer
New ariaNotify() JS API that allows authors to directly tell screen reader what to read
In its most basic form, an author provides a string to be read to the AT

document.ariaNotify(“bold on”);

9 of 20

Notification source

Notifications are sent on behalf of a specific source (document / element)

document.ariaNotify(“bold on”);

document.querySelector(“#foo”).ariaNotify(“bold on”);

(In scope for v1)

10 of 20

Notification priority

Each notification can have a priority of high or normal
Default is normal
Determines where in the output queue the string should be added

document.ariaNotify( “Error connecting to server.", � {“priority”:“high"});

(In scope for v1)

11 of 20

Interrupt property

Each notification can have an interrupt of none, all, or pending.
Determines what should be interrupted from previous notifications sent to the AT
*Out of scope for V1 of API*

document.ariaNotify( "Uploading file untitled-1 to the � cloud.", {“interrupt”:“pending“});

As you may have noticed, priority is very similar to the assertive and polite keywords that can be set by ARIA live regions

One new proposal that comes with ariaNotify is the ability to set the notification interruptability

Interrupt can be none, all or pending, which I will define in more detail in the next slide

These can be used to determine what should be interrupted from the previous notifications sent to the AT

For example, if you are uploading a large list of files to the cloud, you could set interrupt to pending to only announce the current file that is being uploaded, which could provide a less noisy user experience

We believe this property will provide authors with mechanism to aid in reducing noise. However, we are currently working with ATs for full support of interrupt, and as such, it will not be included in the first released version of the API.

12 of 20

Interrupt property

none

Add the current notification, allowing all items to be spoken

all

Add the current notification
If currently speaking a notification from same source, and priority is of equal or lesser importance, silence it
Flush any pending notifications of the same source and equal or lesser priority

pending

Add the current notification
Allow any currently speaking notification to complete
Flush any pending notifications of the same source and equal or lesser priority

(*Out of scope for v1*)

Now I’d like to dive deeper into into the possible values or interrupt. If an author sets interrupt to none, it means that the notification should be announced by the AT, and all other notifications should continue to be spoken as well

An interrupt of all means that the notification should be added.

However, if the currently speaking notification is from the same node source, and the priority of the notification is of equal or lesser importance, that notification should be silenced. Any other notifications matching that same description already in queue should be flushed by the AT

The pending value on the other hand is the same as all, except that it will let any currently speaking notification complete, but may flush any pending notifications of the same source and those that have equal or lesser priority

And as mentioned previously, although we think this will be a value add for authors, it is not in scope for v1 of the API, but we will be working in parallel with AT vendors to unblock this functionality.

13 of 20

Notification Type

Each notification can have a non-localized type
Provides context to the screen reader, allowing users flexibility on how the notification is handled (filter / speech vs. braille / sound effects, etc.)
*Out of scope for V1 of API*

document.ariaNotify( "Audience applause", � {“type”:"reaction“});

The other additional functionality originally proposed within the ariaNotify proposal is an option to provide a notification type.

The type is a non-localized string that provides context to the screen reader, allowing users flexibility on how the notification is handled.

The idea is that an AT could use the type to provide users with a way to filter out notifications based on the type, or provide an option to replace notifications of a given type with a sound effect

There has been several points of feedback from the ARIA WG around this property - some feel it should be some sort of registry or pre-set list of options to make this valuable, others feel that this functionality should be owned by the web app itself, and not something the AT should own.

So the details of this property are still in discussion. As such, this input will not be included in the first released version of the API.

However, one example noted on this slide of the type being used is in an online meeting application.

If a user sends a reaction of applause, the author may send an aria notification that notes this, with the type set to reaction.

An AT may use this to provide more user customization, such as playing a sound effect instead of speaking the notification text.

14 of 20

Fallback mechanism

If the platform doesn’t support ariaNotify, the browser will fallback to live regions

priority – maps to polite / assertive
interrupt – ignored
type – ignored

Won’t apply to IA2 on Windows (just UIA)

15 of 20

AriaNotify in iFrames

Create new Permissions-Policy called aria-notify.
By default aria-notify is allowed in iframes.
Authors can opt iframes out of aria-notify by

<iframe allow="aria-notify 'none'">
Permissions-Policy: aria-notify=(self)

Open WHATWG issue: https://github.com/whatwg/html/issues/11004

16 of 20

Current Status

Prototyped in Chromium behind feature flag on Windows, MacOS, Linux and Android
Test out v1 with the following flags:

--enable-blink-features=AriaNotify
--enable-features=UIAProvider

Test out v2 with the following flags:

--enable-blink-features=AriaNotifyV2
--enable-features=UIAProvider

Draft spec in progress by Github team
Polyfill published by Github team

17 of 20

Demo Video

18 of 20

Next Steps

HTML spec change needed for new iFrame permission policy
Work to publish Aria and HTML spec updates
Work with ATs on consistent support of ariaNotify (and live regions)
Ship UIA in Chromium
Start Origin Trial in Edge/Chromium

Goal: April/May timeframe

19 of 20

Thank you!

Thank you to the following contributors

Evelynn Kaplan, Ethan Jimenez, Doug Geoffray, Keith Cirkel, Clay Miller, Andy Luhrs, Sara Tang

Thank you to the following for reviewing the API and for their advice and guidance throughout the project thus far

Sarah Higley, Scott O’Hara, Aaron Leventhal, Jamie Teh, James Craig, Brett Humphrey, Benjamin Beaudry, and more!

Thank you to the original explainer authors

Travis Leithead, Daniel Libby

20 of 20

Questions/Feedback?