Accessibility in Microsoft Edge with ARIA and ARIA Notify

In the past decade or so, there’s been a push to put everything online. From customer service to interactions with local and national governments, we’ve moved away from the call center to the web and self-service. That push has streamlined interactions and simplified complex relationships, but it has also shown us a significant weak spot: how poorly the web serves people who use assistive technologies.

Design for accessibility is key to any web application. We need the biggest possible reach for our code, and that means providing the necessary hooks for assistive technologies. The more provisions our code has, the better things can be for the widest number of users. Accessibility is a key foundation of modern UI development, as it helps support everyone, not only people with disabilities, but those using text-to-speech in a car, a mother holding a baby, or someone with a broken arm who has to type with one hand for a few weeks. As accessibility advocates regularly note, we are all likely to need help at some point in our lives.

Microsoft has supported accessibility features across its development tools for a long time, building them into its display platforms, including Edge, its Chromium-based browser, and the WebView2 HTML canvas control.

Using ARIA to support assistive technology

A key accessibility technology is ARIA (accessible rich internet applications). A W3C standard, it defines how pages describe themselves to external assistive technologies. In Edge, both HTML and ARIA content is parsed and used to build a separate, accessible view of your site content. Screen readers and similar tools use Edge’s automation APIs to access that view, providing ways to interact with content, such as voice navigation or speech recognition in forms.

ARIA builds a semantic description of web content for use by screen readers and other tools. It mixes computed elements based on the HTML structure of a page and its own attributes. Microsoft has worked with the HTML 5 Accessibility project to show what features are available in Edge, helping on a site redesign that shows sample code for tests and provides a useful guide for how to build ARIA and other accessibility features into your code.

Using Edge Dev Tools to test accessibility

Once you’ve started to build accessibility into your sites, you can use the Edge F12 developer tools to check site code for ARIA support. Right-click on a page and choose Inspect to launch the developer tools. In the top right of the DOM view, you’ll see an icon of a human figure. Click this to open the accessibility tree for the page.

In the lower pane of the developer tools, choose Accessibility to open an inspector, and then scroll through the tree to see ARIA attributes associated with page elements. For example, it can show you the additional markup for a table of contents as a tree with items that can be selected via assistive tools.  This is a quick way to find out if your accessibility features are parsed by Edge and that you’re using the right descriptions.

One criticism of this tool: It’s not as easy to find as it should be. The Accessibility tab wasn’t visible by default. Making it a sub-feature of the Elements tool shows that it’s not a priority. Microsoft’s Edge developer tools team should make it a high-level tool in its own right to show how important accessibility is to the modern web.

Introducing ARIA Notify

ARIA is evolving, with a new set of APIs currently being tested in new builds of Edge. ARIA Notify is designed to work with modern page design techniques where the visual state of a page isn’t necessarily tied to a change in the DOM. If you’re using ARIA, these changes won’t be detected, and although there are workarounds, they aren’t perfect and they won’t work in a number of scenarios, such as in a text editor where you’re making a formatting change, or where a UI element is linked to an asynchronous event and where notifications can happen when a user is interacting with another part of a view.

The new ARIA Notify API avoids many of these issues by offering a basic messaging API that provides any assistive technology (like a screen reader) with the details associated with an action. Say you’re selecting some text in an editor and making it italic. Calling ARIA Notify with the selected text and the action name will deliver the required message to the user.

It’s available as a method attached to the JavaScript document object and any of its nodes, so it’s relatively simple to add ARIA Notify support to most actions. However, that raises another set of issues with overlapping messages and differing levels of importance. You don’t want to lose an important notification in a crowd of messages as a user navigates a menu.

Prioritizing ARIA notifications

ARIA Notify is intended to deliver information about in-browser UI events, so it needs some form of prioritization to handle this type of occurrence. Assistive technologies will need to implement some kind of message queue to categorize messages as either high priority or normal priority. High-priority messages are assumed to have their own queue that overrides normal-priority messages. If a high-priority flag arrives, the current normal-priority message continues to be processed, and the high-priority message then takes first position in the queue.

Microsoft provides two ways to use this new API, as it’s still very much in development. You can use a command line flag to enable it in Edge Canary for your own tests, or if you prefer, you can register your site as part of an Edge Origin Trial to test with external users (in this case, with assistive technology vendors or specific users).

Using Edge Origin Trials

Edge Origin Trials are an interesting tool. Microsoft provides a list of the current trials, which are time-limited, and you can register a site for any of them. If you’re signed in via GitHub, you can register a domain for the trial. You are then issued a token that can be included as a meta element in a page head tag or as a specific HTTP server response. Tokens don’t have to be a fully qualified domain; you can use subdomains for more targeted tests. You can’t use a specific path, as Edge Origin Trials can be enabled only at a domain level.

From a user’s point of view, they don’t need to do anything to test the new feature. As long as their browser supports the feature being tested, the existence of the trial token is enough to enable it. There’s no need to set browser feature flags or use a command line to launch their browser. Tokens last as long as the planned trial; if the trial is extended, they will need to be renewed.

Microsoft’s Edge browser is continuing to evolve to support all users, and the combination of ARIA and ARIA Notify will go a long way to taking existing web applications and supporting a new generation of assistive technologies. Using ARIA Notify, we should be able to support common design elements such as carousels, where not all the content is visible and a user needs to navigate through a dynamically loaded set of content.

Supporting standards like these is vitally important, as the more services (both government and commercial) we put online, the more we risk disenfranchising users who need accessibility support. Adding a little more markup to a page or a new method to a JavaScript operation seems a tiny price to pay for ensuring as many people as possible can use our code.