This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.

ARIA Working Group Road Map

Introduction

This road map describes the current and planned work to be accomplished by the ARIA Working Group. The targets found herein are based on the version of the relevant specification. In order to determine the intended delivery date, please see the ARIA Project Plan.

Achieve Parity with Native Host Language Semantics

There is currently not complete parity between ARIA modules and native host languages used on the web. Where this parity is lacking, authors find it quite challenging to efficiently create the accessible experience afforded by the native host language sementics. Because some authors prefer to create their own custom interfaces rather than use the corresponding host language, the ARIA Working Group believes it is important to address this need. Work in this area will also be needed to implement accessibility support for custom elements. Parity between the native host language and ARIA also makes it possible for the associated native host language’s Accessibility API Mappings specification to map its attributes to those from ARIA. This in turn leads to a more consistent experience for end users, for whom the underlying native host language is largely (if not entirely) irrelevant.

Provide Support for the Accessibility Object Model

The Accessibility Object Model (AOM) is a JavaScript API to allow developers to interact with the accessibility tree associated with web content. As stated in the Explainer: “This API is will be primarily of interest to the relatively small number of developers who create and maintain the JavaScript frameworks and widget libraries that power the vast majority of web apps… This API is also aimed at developers of large flagship web apps that push the boundaries of the web platform. These apps tend to have large development teams who look for unique opportunities to improve performance using low-level APIs like Canvas.”

The ARIA Working Group agreed at TPAC 2017 to support this effort by adding features to ARIA needed by AOM. This support will include:

Develop and Maintain Additional ARIA Features for Authors and End Users

In addition to the work described above, the ARIA Working Group will continue developing, maintaining, and documenting ARIA features authors can use to make their content more accessible to end users. Much of this work will be done on an ad-hoc basis based on feedback from authors and implementors. As such, work in this area will not be itemized here unless it entails a significant amount of effort. Generally speaking, however, the Working Group will:

Specific items that the Working Group plans to accomplish, which will entail a non-trivial amount of effort include:

Ensure Consistency in Platform Accessibility API Mappings

The Working Group believes a consistent (host-language-independent) user experience is desirable. The simplest way to achieve that is to ensure elements are exposed to assistive technologies in a consistent fashion regardless of the native host language chosen by the author. Exposure to assistive technologies is defined in the platform Accessibility API Mappings specifications, not all of which are developed and maintained by the ARIA Working Group. In order to maximize the likelihood of a consistent user experience, the Working Group will:

Back to Top

This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.