Skip to content
Dominic Mazzoni edited this page Feb 9, 2016 · 7 revisions

Web Accessibility API

Introduction

The web platform has a long history of features for developers to use to make their web content more accessible to users with disabilities, from the alt attribute on images to all of WAI-ARIA. A key component of these solutions is that user agents provide an alternate way to interact with a web app using native accessibility APIs specific to each platform. These APIs are used by a variety of assistive technologies, including but not limited to screen readers and magnifiers for visually impaired users, and switch access software and voice control software for motor-impaired users. Accessibility APIs are also often used for automation and automated testing.

Increasingly, apps that take full advantage of some new web platform features are finding it difficult or impossible to make their apps accessible. In particular, one of the biggest challenges happens when a web app uses scripting, and not declarative markup, for a significant portion of its user interface - for example building a portion of the interface using the HTML canvas element (both 2D and WebGL). Authors are forced to create fake invisible DOM elements that represent accessible objects on the screen, a hack that's cumbersome, limited, and ultimately bad for the platform.

The solution is to make it possible for an author to make an app accessible using scripting, where desirable, rather than the only option being accessible features of HTML markup. In a simple use case, the author would be able to set an accessibility property of an HTML element via JavaScript without affecting that element's HTML attributes. In a more complicated use case, the author would be able to create new virtual accessible objects on the page that don't correspond to an HTML element at all, such as controls in a Canvas-based app.

This group is narrowly focused on the goal of creating a scripting API for web accessibility. It's intended to complement existing web accessibility APIs, not replace them. In particular, this solution does not propose new roles, states, and properties an accessible object can have, it just defines a mechanism by which an accessible object with those same roles, states and properties can be defined without necessarily being tied to the HTML DOM.