Compliance → Infrastructure

Accessibility in most design systems means: each component ships with the right ARIA attributes, keyboard navigation works within the component, color contrast passes WCAG AA, and there’s a reduced-motion media query. Component-level compliance. Check the box, move on.

AI breaks this in two ways.

The Shift

First, the content is dynamic. When an LLM streams a response that contains interactive elements — suggested actions, expandable citations, code blocks with copy buttons — focus management becomes a system-level problem. The DOM tree is changing while the user is reading. Where does focus go when new interactive elements appear mid-stream? How does a screen reader announce content that’s arriving token by token? You can’t solve this per-component. You need infrastructure — system-level focus management, live region coordination, and dynamic content announcement that works across component trees the system has never seen before.

The building blocks exist. aria-live regions are a spec primitive. But most design systems either don’t use them or use them narrowly — a toast notification, a form validation message. Nobody has aria-live coordination that works across an entire streaming AI response: what gets announced, what gets batched, what gets suppressed so the screen reader isn’t reading token by token while the user is trying to listen to the answer. That’s the infrastructure gap.

Second — and this is the shift that’s just starting to land — the accessibility tree isn’t just for assistive technology anymore. It’s how AI agents read your interface. Claude’s computer use, Playwright MCP, Browser Use, and most browser automation agents use the accessibility tree as their primary input. Not the DOM. Not a screenshot. The accessibility tree — because it’s the pre-structured, semantic representation of what’s on screen. Your ARIA landmarks, your heading hierarchy, your button labels — that’s the API these agents consume. Which means accessibility quality now directly determines whether AI agents can operate your product. The same semantic structure that powers a screen reader powers the agent that’s booking a flight or filling out a form on behalf of a user. Accessibility isn’t a compliance checkbox. It’s the machine-readable interface layer for every non-visual consumer of your UI — human and artificial.

Where Systems Stand Today

Fluent UI is the clear leader. Tabster provides system-level focus management across dynamically rendered trees. useActiveDescendant() handles keyboard navigation for lists that grow as content streams in. Reduced-motion support includes alternate animations, not just disabled ones. Tabster alone is worth a 6 — the only score above 5 in the entire matrix across any system. Material’s accessibility is solid but per-component — no system-level focus management, no equivalent to Tabster. Neither system has caught the accessibility-tree-as-agent-interface angle yet. See the Fluent UI system page for the deep dive.

What Pushes a Score Up

Per-component ARIA attributes get you to a 3. System-level focus management that works across dynamically rendered trees — where the DOM changes as AI streams content — that’s a 6+. But here’s the shift most people haven’t caught yet: the accessibility tree isn’t just for screen readers anymore. It’s how AI agents see your interface. Claude, Playwright MCP, Browser Use — they all read the accessibility tree as their primary input, not the DOM, not pixels. Your semantic structure is now the API that both humans with assistive tech and machines use to navigate your product. A 7 means the system treats the accessibility tree as a first-class output — focus management for dynamic content, clean semantic structure that reads well to any consumer (human or agent), cognitive load and motion sensitivity as architectural concerns. If your accessibility tree is garbage, your interface is invisible to the fastest-growing category of users on the web.