Debugging with Chromium's Internal Accessibility Page

This article explores the internal accessibility diagnostic page in the Chromium web browser, accessed via chrome://accessibility. It covers how developers and testers use this built-in tool to inspect the browser's raw accessibility tree, toggle specific rendering modes, and capture real-time system events to resolve complex assistive technology issues.

What is the Internal Diagnostic Page?

When assistive technologies like screen readers, magnifiers, or voice control software interact with a web page, they do not read the HTML or DOM directly. Instead, Chromium converts the DOM into a specialized structure called the accessibility tree, which is then exposed to the operating system's accessibility APIs.

The chrome://accessibility page is an internal diagnostic tool that reveals this underlying infrastructure. While the standard Chrome DevTools accessibility pane provides a user-friendly view of a single element's properties, the internal diagnostic page provides a complete, unfiltered dump of the entire accessibility tree and the events firing within the browser.

Controlling Accessibility Modes

For performance reasons, Chromium does not build the full accessibility tree unless it detects that an assistive technology is currently running. The diagnostic page allows developers to manually turn these modes on or off to simulate how the browser behaves when specific tools are active.

The page controls five specific flags:

  • Native: Enables operating system-level accessibility API support for the browser's own user interface (tabs, address bar, menus).
  • Web contents: Enables the basic accessibility tree generation for web pages.
  • Inline text boxes: Computes the exact screen coordinates and bounding boxes of individual words and characters, which is used by screen magnifiers and read-aloud tools.
  • Screen reader: Exposes additional properties required specifically by screen readers, such as table headers and detailed navigation landmarks.
  • HTML: Includes raw HTML attributes in the tree for debugging purposes.

Inspecting the Full Accessibility Tree

Every open tab and extension running in the browser is listed on the chrome://accessibility page. By clicking "Show accessibility tree" next to a specific tab, the browser generates a plain-text representation of the entire tree for that document.

Developers use this view to debug the following issues:

  • Missing Elements: Verifying if an element is accidentally hidden from assistive technology via CSS or ARIA attributes.
  • Incorrect Roles and States: Checking if custom widgets (like dropdowns or modals) are exposing the correct roles, states, and properties to the operating system.
  • Browser UI Issues: Inspecting the "Native" tree to debug accessibility flaws within the Chromium browser frame itself, which standard DevTools cannot access.
  • Tree Filtering: Developers can use the built-in filter controls to show, hide, or highlight specific attributes (such as focusable or invisible) to reduce noise in large documents.

Recording Accessibility Events

Static trees do not always explain why a screen reader fails to announce a dynamic change on a webpage. To solve this, the diagnostic page includes an event recorder.

By selecting "Start recording accessibility events" next to an active tab, developers can interact with the webpage and return to the diagnostic page to view a chronological log of every accessibility event fired. This is essential for debugging:

  • Focus Management: Confirming whether focus events are actually firing when a user opens a dialog or navigates a single-page application.
  • ARIA Live Regions: Verifying if dynamic content updates are triggering the necessary system alerts to notify screen reader users.
  • Event Flooding: Identifying performance bottlenecks where a poorly coded script triggers thousands of redundant accessibility updates, causing assistive technologies to lag or crash.