Creating a more accessible web with Aria Notify

[TWF Bot]

We're excited to announce the availability, as a developer and origin trial, of ARIA Notify, a new API that's designed to make web content changes more accessible to all users. You can try ARIA Notify today as an Origin Trial starting with Microsoft Edge 136, or locally by enabling the --enable-blink-features=AriaNotify feature flag. ARIA Notify is designed to address scenarios where a visual change that's not tied to a DOM change and not accessible to assistive technology users, happens in the page. Examples include changing the format of text in a document, or when a person joins a video conference call. Developers have come to rely on ARIA live regions as a limited workaround. ARIA Notify is an imperative notification API that's designed to replace the usage of ARIA live regions, and overcome its limitations, in these scenarios.

The problems with ARIA live regions​

For individuals who are blind or have low vision, identifying non-user-initiated changes in the content of a web page can be very challenging. ARIA live regions are the only mechanism available today that communicates dynamic content changes to users of assistive technology. However, ARIA live regions are tightly coupled with DOM elements because they're built around the assumption that visual changes happen in sections or UI widgets of a web page. But many important changes can happen on a web page without the DOM of the page being modified. Consider these two examples:

• The user is interacting with a text editing area. The user highlights a word and then presses the Ctrl+B shortcut to make it bold. In this scenario, no UI elements were used by the user, and the DOM didn't necessarily change. The user should still hear confirmation that the action was successful.
• The user is composing an email and presses the Send button. In normal circumstances, the message is sent, and a focus change occurs, which confirms that the action was successful. But, if the action is delayed or later fails, the user should still hear a notification about the delay or failure.

In these scenarios, developers tend to resort to using workarounds where they mimic dynamically changing content using DOM nodes that are placed offscreen. Unfortunately, this can lead to unexpected side effects for end users, like making the offscreen content accidentally discoverable by screen reader users with their virtual cursor, or not accessible if a modal dialog is opened and the offscreen content is not placed within it. In addition, using ARIA live regions in these scenarios also comes with timing issues that developers must deal with, such as having to wait for an undetermined amount of delay between creating a region and adding the content into it. The ARIA Notify API addresses these issues.

Introducing the ARIA Notify API​

ARIA Notify is an ergonomic and predictable way to tell assistive technologies (ATs), such as screen readers, exactly what to announce to users and when. In its simplest form, developers can call the ariaNotify() method with the text to be announced to the user. The method is available both on the document object and on DOM nodes.
// Dispatch a message associated with the document.
document.ariaNotify("John Doe is connected");

// Dispatch a message associated with an element.
document.querySelector("#text-editor").ariaNotify("Selected text is bold");
When called on the document object, the language of the provided notification string is assumed to match that of the document. When called on an element, the element's nearest ancestor's lang attribute is used to infer the language. The ARIA Notify API also lets developers hint to an AT about the importance of notifications to ensure that important messages that the user should be aware of are announced with urgency. To do this, developers can use the priority option. This option indicates how the AT should rank the notification with respect to other, pending, notifications:

• high - The AT should add the notification to the end of any other pending high priority notifications but before all normal priority pending notifications.
• normal (default) - The AT should add the notification to the end of all pending notifications.

Here's an example showing how to set priorities:
// Dispatch a normal priority notification about a background task status update.
document.ariaNotify("Background task completed", { "priority":"normal" });

// Dispatch a high priority notification that data may be lost.
document.ariaNotify("Unable to save changes, connection lost", { "priority":"high" });
In this example, assuming that the normal priority notification hasn't already been announced, the high priority notification is guaranteed to be announced first, followed by the normal priority notification.

Try ARIA Notify today and let us know what you think​

We're excited that ARIA Notify is now ready to be tested by developers, either locally, or as part of a Microsoft Edge Origin Trial to gather developer feedback on the API. If you want to test ARIA Notify in Microsoft Edge on your own device only, start Edge from the command line and use the --enable-blink-features=AriaNotify argument to enable the feature. For example, if you're using Microsoft Edge Canary on Windows, run the following command in a command prompt: "C:\Users\<username>\AppData\Local\Microsoft\Edge SxS\Application\msedge.exe" --enable-blink-features=AriaNotify To test your entire website with users instead, register your website for an Edge Origin Trial:

• Go to AriaNotify API on the Microsoft Edge Origin Trial site.
• Sign-in to the site with your GitHub credentials.
• And then register for the Origin Trial.

To learn more about the API, check out the ARIA Notify explainer. We'd love to hear your feedback about the API, to ensure that our solution meets your needs. Let us know your thoughts by opening a new issue on our GitHub repository.

Continue reading...