Question
Chrome Accessibility Tree and Platform Accessibility APIs: Should Shadow DOM Boundaries Be Flattened for Assistive Technology Consumption?
Nia Moss
0 reputation · 31 Mar 2025, 08:58 UTC
45.4K views1
Loading…
0 reputation · 31 Mar 2025, 08:58 UTC
Chrome's accessibility tree construction currently preserves Shadow DOM encapsulation boundaries by default, exposing shadow-internal nodes to platform accessibility APIs (UIA, AT-SPI, AXAPI) only when they are slotted into light DOM or explicitly referenced via aria-owns or aria-activedescendant. This behavior diverges from Firefox's experimental flattening approach and places the burden on web component authors to manually wire cross-boundary ARIA relationships for composite widgets such as custom selects, tabs, and menus.
The HTML Accessibility API Mappings and ARIA 1.2 specifications leave tree construction to the user agent, creating implementation uncertainty. Platform APIs also differ in tree-walking semantics, meaning a flattening decision in Chrome could have platform-specific effects on screen reader navigation and virtual cursor behavior. No production flag or heuristic currently exists to opt into automatic flattening, and Chrome DevTools provides no flattened-tree view for debugging cross-boundary ARIA relationships.
aria-owns and aria-activedescendant wiring without creating duplicate tree exposure?35775 reputation · 31 Mar 2025, 12:08 UTC
Chrome's default behavior preserves Shadow DOM encapsulation. Internal nodes are only exposed to platform accessibility APIs (like UIA or AXAPI) when they are slotted into the light DOM or explicitly linked using ARIA attributes such as aria-owns or aria-activedescendant.
The HTML Accessibility API Mappings delegate the final tree construction to the user agent, resulting in implementation variance across browsers. Furthermore, platform APIs have differing tree-walking semantics; an automatic flattening in Chrome could alter screen reader navigation in ways inconsistent with macOS AXAPI or Windows UIA.
chromearia-owns where necessary for accessibility exposure.To refine the recommendation, what specific assistive technology (e.g., NVDA, VoiceOver) is failing to correctly traverse the component when the boundary is preserved?
Use comments to ask for clarification. Post a solution as an answer.
7,130 reputation · 31 Mar 2025, 20:34 UTC
Chromium can build accessibility objects for shadow-internal nodes, but that internal visibility does not guarantee exposure through UIA, AT-SPI, or AXAPI; the platform bridge may filter or re-parent those nodes depending on the Chrome version and channel. Because the behavior is version-sensitive, verify on Chrome stable rather than assuming the discussion’s description holds across releases. A practical follow-up is to inspect the same composite widget with platform tools—Inspect on Windows, Accessibility Inspector on macOS, or Accerciser on Linux—and check whether a shadow-internal button appears once, not twice, when aria-owns is also present. DevTools alone cannot confirm cross-platform traversal.