The Accessibility Object Model project aims to improve certain aspects of the user and developer experiences concerning the interaction between web pages and assistive technology.

In particular, this project is concerned with improving the developer experience around:

• building Web Components which are as accessible as a built-in element;
• expressing and modifying the semantics of any Element using DOM APIs;
• expressing semantic relationships between Elements;
• expressing semantics for visual user interfaces which are not composed of Elements, such as canvas-based user interfaces;
• understanding and testing the process by which HTML and ARIA contribute to the computation of the accessibility tree.

By reducing the friction experienced by developers in creating accessible web pages, and filling in gaps in what semantics may be expressed via DOM APIs, the APIs proposed in the Accessibility Object Model aim to improve the user experience of users interacting with web pages via assistive technology.

Introduction

Explainer

Please refer to the Accessibility Object Model Explainer for the background and motivation.

If you have questions, comments, or other feedback, please file an issue on GitHub.

Structure of Accessibility Object Model Specs

The specifications which comprise the Accessibility Object Model are split into loose “phases”, each of which may take the form of a modification to an existing spec, or a new API.

While the term “phases” indicates a rough ordering, based on expected time to completion and relative urgency of work, it should not be expected that one phase must be complete before work begins on the next, nor that phases will be completed in strict order.

See the project phases section for links to each phase.

Document Scope

The Accessibility Object Model specs are narrowly focused on the goals described in the Abstract. They are intended to complement existing web accessibility APIs such as [[!WAI-ARIA]], not replace them. In particular, this spec attempts to avoid proposing new roles, states, and properties of accessible objects except where necessary.

Criteria for Inclusion

This specification is not intended to solve all accessibility problems on the Web. It is currently impossible to make some web features accessible, so the primary goal is to resolve immediate needs quickly for existing, inaccessible web interfaces. The specification editors are intentionally deferring many useful ideas in order to maintain a realistic timeline for highest priority features.

We have defined Inclusion/Exclusion Criteria in order to clarify exactly what will be considered in-scope.

Phases

Phase 1a: ARIA Reflection

See the ARIA Reflection document.

Phase 1b: Custom Element Semantics

See the Custom Element Semantics document.

Phase 2: User Action Events

See the Input Events document.

Phase 3: Virtual Accessibility Nodes

See the Virtual Accessibility Nodes document.

Phase 4: Computed Accessibility Tree

See the Computed Accessibility Tree document.

Acknowledgements

Many thanks for valuable feedback, advice, and tools from: Alex Russell, Bogdan Brinza, Chris Fleizach, Cynthia Shelley, David Bolter, Domenic Denicola, Ian Hickson, Joanmarie Diggs, Marcos Caceres, Nan Wang, Robin Berjon, and Tess O’Connor.

Bogdan Brinza and Cynthia Shelley of Microsoft contributed to the first draft of this spec but are no longer actively participating.