In 2025, something quietly remarkable happened: the dominant method for AI agents to perceive a web page became the accessibility tree. The same data structure that browsers expose to screen readers for blind and low-vision users. Playwright's MCP server, released by Microsoft in March 2025, sends agents not screenshots or raw HTML but structured ARIA snapshots: roles, names, states, each tagged with a reference ID.1 The efficiency argument is brutal in its simplicity. An accessibility snapshot runs 2 to 5KB. A screenshot of the same page runs 100KB or more.2 For an agent burning through context windows, that's the whole ballgame.
A specification designed explicitly as a repair mechanism for human accessibility — the First Rule of ARIA is literally "use native HTML instead if you can"3 — had become the primary lens through which machines read the web.
We wanted to talk to someone who was in the room when ARIA's semantics were being debated. Dottie Parsons was an invited expert on the W3C WAI-ARIA working group from 2009 to 2015, after a first career in library science and a pivot into web accessibility consulting. She's now semi-retired in Portland, Oregon, where she keeps bees and consults part-time on design system accessibility. She does not, technically, exist. But the working group she served on very much did, the debates she describes are well-documented, and the ambivalence she voices is one we've heard from real practitioners who asked not to be the person saying it on the record.
You spent years on a specification designed for screen readers. Now AI agents are the fastest-growing consumers of that same data. What's that feel like?
Dottie: So I used to be a cataloger. Library science. And there's this moment every cataloger has where you discover someone is using your subject headings for something you never imagined. You carefully assigned "Bee culture — Oregon — Periodicals" and then someone's using your metadata to train a recommendation engine. And you think, well, the classification was good, so it works. But also, that's not what "Bee culture — Oregon — Periodicals" was for.
That's roughly where I am. Except the stakes are higher because the original users — screen reader users, people navigating by keyboard — they're still there. They didn't go away because agents showed up.
What were ARIA roles actually meant to carry? Beyond labeling an element?
Dottie: So much more than a label. When we debated what role="combobox" should mean, we weren't asking "what should this element be called." We were asking: what does a blind person expect to happen when they land on this thing? We borrowed from desktop GUIs — Windows, macOS, GNOME — because screen reader users already knew those interaction patterns.4 A combobox means Alt+Down Arrow opens the list. A tree means Right Arrow expands a branch. The role was a promise about behavior, not a tag.
And then there were live regions. That was some of the most careful work we did. You have a screen reader user navigating a page sequentially, in time. Something changes. A chat message arrives, a form error appears. Do you interrupt them? How urgently? We designed aria-live="polite" to wait until they finished what they were doing. "assertive" interrupts immediately. The whole system was built around human attention as a finite, sequential resource.
An agent snapshots the page on demand. It has no concept of being interrupted. That entire layer just doesn't exist for them.
Does it bother you that agents discard those layers?
Dottie: "Bother" is too simple.
They take the skeleton and leave the body. The role, the name, the state. That's what agents extract.
And honestly? That's the useful part for what they're doing. I'm not going to sit here and pretend an AI needs to know about polite versus assertive announcements.
What gets to me is subtler. When we wrote those roles, we were encoding an entire interaction model. A role="button" doesn't just say "this is a button." It says "this responds to Enter and Space, this is focusable, this has an accessible name that tells you what it does."5 An agent reads role="button", issues a click, and moves on. Got what it needed. But the promise embedded in that role, the keyboard contract, the behavioral expectation — that's just gone. Evaporated. Like reading a love letter for the mailing address.
The WebAIM Million report shows that pages with ARIA have more accessibility errors than pages without it — 59 errors on average versus 42.6 That was true before agents entered the picture.
Dottie: Yeah.
Just "yeah"?
Dottie: What do you want me to say? We built a repair tool and people used it to make things worse. A hundred and thirty-three million ARIA attributes detected across the top million sites in 2026. Six times what it was in 2019.7 And the more ARIA you find on a page, the more likely it is to be broken. It's like handing someone a fire extinguisher and watching them use it as a doorstop while the building burns.
The First Rule of ARIA exists precisely because we knew this would happen. A <button> element is accessible by default. It handles keyboard events, it's focusable, screen readers announce it correctly. You don't need ARIA for that. But developers reach for <div role="button"> and then forget to add the keyboard handling, and now you have an element that claims to be a button but doesn't act like one.8 That was already a catastrophe for screen reader users. Now agents trip over it too.
There's an argument that agent demand could actually improve ARIA implementation. If broken semantics break agent tasks, companies have a financial incentive to fix them. Do you buy that?
Dottie: I want to. God, I want to. Because we spent decades making the moral argument — "people with disabilities deserve equal access to the web" — and the numbers kept getting worse. If the money argument works where the moral argument didn't, I should be grateful, right?
But I've seen this movie before. Adrian Roselli, who's on the ARIA working group, flagged this in late 2025.9 If you tell developers "ARIA is how AI agents read your site," you get the same thing we got with SEO and meta tags. Keyword stuffing. People cramming aria-label onto everything not because it helps a screen reader user but because they think it helps their agent discoverability. And bad ARIA is worse than no ARIA. A page with no ARIA, the screen reader at least gets the native HTML semantics. A page with wrong ARIA actively lies to you.
So my honest answer is: maybe. Maybe agent demand creates pressure for correct implementation. Or maybe it creates pressure for more implementation, which historically has meant more incorrect implementation. I genuinely don't know yet. Ask me in three years.
You called ARIA a "repair mechanism." Now it's arguably the primary interface between AI and the web. Funny or alarming?
Dottie: Ask my bees. They'd tell you that any structure built well enough gets colonized by something you didn't plan for.
The accessibility tree was designed as a bridge between browsers and assistive technologies. A very specific bridge, for very specific users, with very specific needs. And it turns out that "tell me what's on this page in a way I can act on without seeing it" is a problem that applies to more than blind people. It applies to anything that isn't a pair of human eyes.
The cataloger in me thinks: good metadata is good metadata. If the classification is rigorous, it serves uses you didn't anticipate. That's practically the definition of a standard done right.
But the accessibility engineer in me thinks: the people I built this for are still underserved. Screen reader users still hit unnamed buttons, broken comboboxes, missing labels. Every single day. And now there's this enormous new constituency, agents making billions of requests, consuming the same infrastructure. If the investment follows the money, it follows the agents. And the original users become what, exactly? A beneficial side effect of their own standard?
That's the part I sit with.
I spent five years in working group meetings arguing about whether a tree node should announce "expanded" or "open." We chose "expanded" because it matched what JAWS users expected from Windows Explorer. That level of care, that specificity about human experience — I don't know where it lives in a world where the biggest consumer of your work is a language model that doesn't experience anything at all.
Footnotes
-
TestDino, "What is the Accessibility Tree?" https://testdino.com/blog/accessibility-tree ↩
-
DEV Community (stevengonsalvez), "Browser Tools for AI Agents Part 1." https://dev.to/stevengonsalvez/browser-tools-for-ai-agents-part-1-playwright-puppeteer-and-why-your-agent-picked-playwright-k71 ↩
-
W3C WAI-ARIA Overview. https://www.w3.org/WAI/standards-guidelines/aria/ ↩
-
W3C ARIA APG, "Developing a Keyboard Interface." https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/ ↩
-
MDN Web Docs, "WAI-ARIA Roles." https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles ↩
-
WebAIM Million 2026. https://webaim.org/projects/million/ ↩
-
WebAIM Million 2026. https://webaim.org/projects/million/ ↩
-
Level Access, "WAI-ARIA Best Practices." https://www.levelaccess.com/blog/wai-aria-guidance-best-practices-for-accessible-web-interfaces/ ↩
-
Matthew Stephens (Medium), "Why AI Agents Are Changing the Game for Accessibility." https://matthewlarn.medium.com/why-ai-agents-are-changing-the-game-for-accessibility-8a6a59a71f6a ↩