Skip to main content

5 posts tagged with "accessibility"

View all tags

The Accessibility Tree Is Your Newest Public API

· 9 min read
Tian Pan
Software Engineer

For a decade, accessibility was the work that slipped. It lived at the bottom of the backlog, resurfaced during compliance audits, and got patched with just enough ARIA to quiet the linter. The economic argument never landed because the affected users were a minority whose churn never showed up in a dashboard anyone was paged about.

Then browser agents arrived, and the economics inverted overnight. Products like ChatGPT's browsing mode, Claude's computer use, and the wave of Playwright-MCP-based automation don't see your pixels. They read the browser's accessibility tree — the same semantic structure screen readers have consumed for twenty years. Every unlabeled button, every div masquerading as a link, every custom dropdown that doesn't expose its state is now invisible not just to blind users but to the agents your business partners are integrating against. A decade of deferred accessibility debt just became integration debt, and integration debt has paying customers attached.

When Streaming Tokens Meet the Screen Reader: The Accessibility Debt of Generative UIs

· 10 min read
Tian Pan
Software Engineer

The most celebrated interaction pattern of the last two years — text that materializes word by word, as if the machine were thinking out loud — is, for a screen reader user, closer to noise than to language. Every token your model emits is a DOM mutation. Plug a naive aria-live region into that stream and the screen reader will try to announce each mutation as it lands, producing a stuttering, overlapping torrent that resets mid-sentence dozens of times per second. The feature that makes your product feel alive is the same feature that makes it unusable for the people who depend on assistive technology.

This is accessibility debt, and generative UIs accrue it faster than any interface pattern before them. The reason is structural: traditional web content is static and predictable, so you can reason about it once and ship. A generative interface changes on every interaction — one prompt returns a list, the next returns a table, the next streams 600 words of prose followed by a tool-call widget. There is no fixed DOM to audit, no stable tab order to verify, no single snapshot that represents "the page." The accessibility contract has to hold across an infinite space of generated outputs, and almost nobody is testing for that.

The AI Accessibility Audit Nobody Runs

· 11 min read
Tian Pan
Software Engineer

Open your agent product, turn on VoiceOver, and hit send on any prompt. If you have a typical streaming UI with an inline reasoning trace, what you will hear in the next thirty seconds is not your product. It is a torrent of partial tokens, mid-word reflows, status changes nobody announced, and a reasoning monologue your sighted users opted into but your blind users cannot escape. The interface that demoed beautifully on stage is, to a screen reader, a denial-of-service attack delivered as speech.

This is the audit nobody on the AI team runs. The design review approved the streaming animation. The eval suite measured answer quality. The latency dashboard tracked time-to-first-token. None of those instruments noticed that the affordance making the product feel fast and thoughtful for one cohort makes it unusable for another. And that omission is starting to show up in pro-se lawsuit filings — the same federal courts that have been processing accessibility complaints against e-commerce sites for a decade are now seeing AI-interface complaints rise sharply, with one tracker reporting a 40% year-over-year increase in 2025 alone.

Generative UI as a Production Discipline: When the Model Renders the Screen

· 12 min read
Tian Pan
Software Engineer

The button label that shipped to your users last Tuesday was never seen by a copywriter, never reviewed in Figma, never QA'd, and didn't exist until inference time. It was generated by a model that decided, mid-conversation, that the right way to collect a shipping address was a six-field form rendered inline rather than three more turns of prose. The form worked. The label was fine. Nobody on the team can tell you which model run produced it, because the trace was rotated out of hot storage and the eval suite tests text outputs, not component graphs.

This is generative UI in production: the model is no longer just a text generator that occasionally invokes a tool. It is a UI compiler whose output is a component tree, and the design system is now a contract the model is constrained to rather than a guideline a human loosely follows. The shift breaks an entire stack of assumptions — QA against static specs, accessibility audits of fixed layouts, copy review of finalized strings, design-system adherence checks at build time — and most teams ship the feature before they have replaced any of them.

The Accessibility Gap in AI Interfaces Nobody Is Shipping Around

· 8 min read
Tian Pan
Software Engineer

Most AI teams run accessibility audits on their landing pages. Almost none run them on the chat interface itself. The gap isn't laziness — it's that the tools don't exist. WCAG 2.2 has no success criterion for streaming content, no standard for non-deterministic outputs, and no guidance for token-by-token delivery. Which means every AI product streaming responses into a <div> right now is operating in a compliance grey zone while breaking the experience for a significant portion of its users.

This isn't a minor edge case. Blind and low-vision users report information-seeking as their top AI use case. Users with dyslexia, ADHD, and cognitive disabilities are actively trying to use AI tools to reduce reading load — and the default implementation pattern actively makes things worse for them.