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 views0
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?A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
chrome