Platform-Independent Accessibility API: Accessible Document Object Model
Andres Gonzalez, Loretta Guarino Reid · 2005 · Proceedings of the 2005 International Cross-Disciplinary Workshop on Web Accessibility (W4A) · doi:10.1145/1061811.1061824
Summary
This paper, authored by Adobe engineers, addresses a fundamental problem in cross-platform accessibility: application developers who want to support assistive technologies must implement separate integrations for each operating system's accessibility API — MSAA on Windows, the Mac Accessibility API on macOS, ATK (Accessibility Toolkit) on Linux, and the Java Accessibility API for Java applications. Each API has its own object model, event system, and communication mechanism, forcing significant duplicated effort. The authors propose the Accessible DOM, a platform-independent accessibility API built as an extension to the W3C DOM Level 3 Core specification. The Accessible DOM adds a new accessibility module containing four key interfaces: AccessibleNode (extending DOM's Node with properties like accessibleName, accessibleType, accessibleValue, accessibleState, boundingRect, and relationships), AccessibleDocument (extending Document with focus tracking, selection tracking, and relationship creation), Relationship (expressing semantic connections between objects beyond parent-child hierarchy, such as label-for, header-for, and annotation-for), and Collection (grouping nodes by accessible type for efficient navigation). The architecture uses thin adapter layers to map the Accessible DOM to platform-specific APIs, allowing both platform-specific assistive technology clients and new platform-independent clients to connect. The paper provides a complete IDL specification for the accessibility module and demonstrates how the Accessible DOM can be mapped to MSAA, including a detailed table mapping DOM Level 3 event types to MSAA events.
Key findings
The paper's analysis of existing accessibility APIs reveals they share common core features: accessible objects with name/role/value/state properties, a hierarchical tree structure, events for UI and content changes, and inter-process communication between servers (applications) and clients (assistive technologies). However, existing APIs have significant limitations that the Accessible DOM overcomes. First, platform APIs have fixed sets of object types with predefined behaviors, using a catch-all "unknown" role for anything that doesn't fit — insufficient for complex documents with tables, forms, annotations, and multimedia. The Accessible DOM's extensible type system and Relationship interface allow richer semantic expression. Second, existing APIs express only parent-child relationships through their tree structure, while documents require label-for, header-for, and annotation-for relationships that the Accessible DOM's Relationship interface captures explicitly. Third, the Collection mechanism enables efficient structural navigation — for example, retrieving all headings in a document without sequential traversal, directly supporting UAAG 1.0 Guideline 9's requirement for navigation mechanisms. The paper also defines an Accessible DOM Conformance Profile requiring support for DOM Level 3 Core, DOM Level 3 Events (including UI, mouse, text, keyboard, and mutation events), DOM Level 2 Range, and DOM Level 2 Traversal, plus the new accessibility interfaces. The MSAA adapter mapping reveals gaps: MSAA lacks equivalents for DOMFocusOut, mouse/keyboard input simulation, form submission, and attribute name changes.
Relevance
This paper is historically significant as an early formal attempt to create a unified accessibility API, authored by members of Adobe's Acrobat Accessibility team who faced the cross-platform problem directly. The concepts proposed here — accessible properties on DOM nodes, explicit semantic relationships between elements, typed collections for structural navigation, and a platform-independent accessibility tree — directly influenced the development of WAI-ARIA and the modern Accessibility Object Model (AOM) that is currently being standardized by W3C. The Relationship interface anticipates ARIA's relationship attributes (aria-labelledby, aria-describedby, aria-owns). The AccessibleNode interface foreshadows the AOM's AccessibleNode proposal. For practitioners, the paper provides a clear conceptual framework for understanding how assistive technologies interact with web content: the accessibility tree as a parallel structure to the DOM, accessible properties exposing semantic information, relationships connecting elements beyond hierarchy, and events propagating state changes. These concepts are now fundamental to how browsers expose web content to screen readers through platform accessibility APIs.
Tags: accessibility API · DOM · cross-platform accessibility · assistive technology · MSAA · screen readers · platform independence · accessibility architecture
Standards referenced: UAAG 1.0 · MSAA · W3C DOM Level 3