Platform-Specific Accessibility APIs Supported by Chromium

This article provides a comprehensive overview of the platform-specific accessibility Application Programming Interfaces (APIs) supported by the Chromium web browser. Because assistive technologies like screen readers and magnifiers rely on operating system-level frameworks to interpret and interact with digital content, Chromium translates its internal accessibility tree into the native APIs of Windows, macOS, Linux, Android, and ChromeOS.

To make web content accessible across different operating systems, Chromium compiles the Document Object Model (DOM) into a standardized, internal structure known as the Accessibility Tree (AXTree). Chromium then uses platform-specific bridge code to expose this tree to the host operating system's native accessibility APIs. Here are the specific APIs Chromium supports for each platform.

Windows

Windows has the most complex accessibility ecosystem due to the coexistence of legacy and modern frameworks. Chromium supports three major APIs on Windows to ensure compatibility with various screen readers like NVDA, JAWS, and Windows Narrator:

  • Microsoft Active Accessibility (MSAA): This is the legacy API introduced in Windows 95. While limited in scope for modern web applications, Chromium still supports MSAA as a baseline fallback and to handle basic UI elements.
  • IAccessible2 (IA2): Developed to fill the gaps left by MSAA, IA2 is heavily used by third-party screen readers like NVDA and JAWS. Chromium has deep support for IA2, using it to expose rich text attributes, tables, and WAI-ARIA (Accessible Rich Internet Applications) roles.
  • UI Automation (UIA): This is Microsoft’s modern accessibility framework. Chromium has progressively integrated UIA support, allowing seamless interaction with the built-in Windows Narrator and modern Windows assistive tools.

macOS

On Apple’s desktop operating system, Chromium integrates directly with Cocoa frameworks to support the built-in VoiceOver screen reader and other macOS assistive utilities.

  • NSAccessibility: Chromium maps its internal AXTree directly to the NSAccessibility protocol. Through this API, Chromium exposes web elements as native macOS accessibility objects, translating HTML and ARIA attributes into macOS-specific roles, subroles, and notifications that VoiceOver can easily process.

Linux

For Linux desktop environments (such as GNOME and KDE), Chromium relies on the standard open-source accessibility infrastructure primarily used by the Orca screen reader.

  • ATK (Accessibility Toolkit): Chromium implements ATK interfaces to represent the web content's UI elements in memory.
  • AT-SPI (Assistive Technology Service Provider Interface): Working in tandem with ATK, Chromium uses AT-SPI2 over D-Bus to communicate the ATK data to external assistive technologies. While Chromium creates the elements using ATK, AT-SPI is the inter-process communication layer that delivers the information to the screen reader.

Android

On Android devices, Chromium must bridge web content to the mobile operating system's touch-focused accessibility framework, predominantly for the TalkBack screen reader.

  • Android Accessibility Framework: Chromium uses the AccessibilityNodeProvider API to build a virtual view hierarchy of the webpage. Each HTML element in the AXTree is translated into an AccessibilityNodeInfo object. This allows Android to treat nodes within a webpage just like native Android UI views, enabling swipe navigation and touch exploration.

ChromeOS

Because ChromeOS is built directly on top of the Chromium browser, it does not need to translate the AXTree into a third-party OS API.

  • Chrome Automation API: Chromium uses an internal extension API called chrome.automation. The built-in screen reader, ChromeVox, and the Select-to-Speak feature run as extensions within the browser itself. They read the AXTree directly via the Automation API, resulting in faster performance and lower memory overhead compared to traditional OS bridges.