Ramona Tabindex — a name her colleagues in the accessibility community find either perfectly apt or suspiciously on-the-nose — has spent seventeen years in WCAG compliance work. She started when WAI-ARIA was still a working draft. Since then, she's conducted accessibility audits for three Fortune 500 companies, two government agencies, and what she describes as "an uncountable number of startups who thought adding role="button" to a div was the same as making a button." She now runs an independent consultancy. We spoke over video call; behind her, a whiteboard listed what appeared to be the same six items, underlined multiple times.
You've been doing this work since before ARIA was even an official standard. What does that arc feel like from the inside?
I started in 2009. ARIA was a working draft. Richard Schwerdtfeger at IBM had proposed it back in 2006, and we were all genuinely excited.1 Not many of us, but genuinely excited. Dynamic web content was exploding, AJAX everywhere, and screen readers were just... lost. ARIA was going to fix that.
Then it took until 2014 to become a W3C Recommendation.2 Six years of pushing for something that wasn't even official yet. You develop a certain tolerance for being early.
The WebAIM Million data shows that pages using ARIA actually have more accessibility errors than pages without it. How do you explain that to someone encountering it for the first time?
This is the thing I've been explaining for a decade, and every year the data gets worse and I explain it again. In 2025, WebAIM detected over 105 million ARIA attributes across the top million home pages. Averaging 106 per page. An 18.5% increase in a single year.3 Pages with ARIA averaged 57 errors. Pages without ARIA? Twenty-seven.4
Here's what happens. A developer runs an automated scan. The scan says "this dropdown needs an accessible name." So they add aria-haspopup="true" and aria-expanded="false". Done. Ticket closed. Except ARIA doesn't add behavior. It only changes how assistive technologies perceive an element.5 If you don't write the JavaScript to update aria-expanded when the dropdown actually opens, a screen reader user now has a dropdown that announces itself as permanently closed. You've made it worse than having no ARIA at all.
And this isn't edge cases. Thirty-five percent of ARIA menus introduced new accessibility barriers because of missing required interactions or roles.3 The first rule of ARIA — literally, the W3C's own first rule — is "don't use ARIA."6 Use native HTML. Only reach for ARIA when native elements can't do the job. Most production ARIA in the wild violates rule one.
So when someone asks me how pages with more accessibility markup have worse accessibility — it's like asking why houses with more smoke detectors have more fires. They don't. But houses that need a lot of smoke detectors tend to have other problems.
The WebAIM Million has tracked the same six most common error categories for seven consecutive years.7 What's on your whiteboard?
(turns to look at it) Low contrast text. Missing alt text. Missing form labels. Empty links. Empty buttons. Missing document language.
I could tattoo them at this point.
In the past year, AI agent frameworks have started querying the accessibility tree as their primary way of perceiving web pages.8 What was your reaction when you first saw that?
I laughed. Not a joyful laugh. More like the laugh you produce when you've been telling someone for fifteen years that the bridge has a structural problem, and they ignore you, and then a truck falls through it, and they call a meeting to discuss truck-bridge compatibility.
The accessibility tree was built so that screen reader users could navigate dynamic content. That was the entire point. And now it turns out it's also the most efficient way for an AI agent to understand a page — roughly 4,000 tokens for an accessibility snapshot versus 50,000 for a screenshot.9 So suddenly everyone's very interested in the accessibility tree. Not because of the people it was built for. Because it's cheap and structured and it works.
When it works.
The CHI 2026 study out of Berkeley and Michigan tested Claude on everyday tasks: 78% success under standard conditions, drops to 42% with keyboard-only navigation.10 That 42% is what screen reader users have been living with. We just didn't have a benchmark anyone cared about.
Does agent adoption of the accessibility tree ultimately help the accessibility cause?
I go back and forth on this weekly. The optimistic version: agents create a financial incentive for good ARIA implementation. When a broken aria-label means your AI agent can't complete a checkout flow, that's a measurable business cost. Fifteen years of "it's the right thing to do" couldn't move budgets. Maybe "your agent is broken" will.
But then I think about what actually happens when financial incentives meet markup. Adrian Roselli, who's on the W3C ARIA Working Group, wrote about this in late 2025.11 SEO consultants keyword-stuffed alt text for decades. The moment OpenAI published guidance telling publishers to follow ARIA best practices for Atlas, Roselli predicted we'd see aria-roledescription="FREE no-cost cheap mouthwash lids" within a year. He's probably right. The incentive is to make ARIA readable for bots, not navigable for people. Those are very different things.
So agents inherit the same broken feedback loop that screen reader users have dealt with for years?
The people who could fix it never learn it's broken, because the people who experience the failure can't reach them.
Screen reader users who hit broken ARIA just navigate away. They don't file bugs. The developers never learn the implementation was wrong. Eighty-four percent of organizations say accessibility is a top priority; 68% can't test continuously.12 That gap is where everything dies.
Agents? Same story, different costume. An agent that fails on a badly implemented page — that failure gets attributed to the model. "Claude couldn't complete the task." Not "the page had broken ARIA." Same attribution problem. Same severed wire.
What would actually close that loop?
Consequences. Not standards. Not better specs. Not another .txt file. Liability surfaces. When a screen reader user can't complete a government form, someone should be accountable in a way that reaches the developer's sprint board. We've got roughly 4,600 ADA web accessibility lawsuits a year now13 — that's moved the needle more than any standard ever did. It's depressing that it takes legal exposure, but I've been at this seventeen years. I'll take what works.
The thing I keep coming back to: automated scanners catch maybe a third of real issues.14 The 95.9% failure rate in the 2026 WebAIM data? That's the floor.7 The actual rate of meaningful non-conformance is certainly higher. We are building agent infrastructure on a foundation that's been documented as broken every single year for seven years, and the response is still "we'll add more ARIA."
I love this field. I do. But sometimes it feels like being the world's most patient person in a room where nobody's listening — and now there are robots in the room too, and they're also not listening, but at least they're taking notes.
Footnotes
-
WAI-ARIA was proposed in 2006 by Richard Schwerdtfeger at IBM. https://grokipedia.com/page/WAI-ARIA ↩
-
WAI-ARIA became a W3C Recommendation on March 20, 2014. https://en.wikipedia.org/wiki/WAI-ARIA ↩
-
WebAIM Million 2025 detected 105M+ ARIA attributes; 35% of ARIA menus introduced new barriers. https://news.designrush.com/wcag-2-accessibility-failures-homepages-web-development-2025 ↩ ↩2
-
Pages with ARIA averaged 57 errors vs. 27 without. https://beaccessible.com/post/web-accessibility-statistics/ ↩
-
WAI-ARIA does not add behavior; it changes only assistive technology perception. https://www.levelaccess.com/blog/wai-aria-guidance-best-practices-for-accessible-web-interfaces/ ↩
-
The first rule of ARIA: don't use ARIA. https://en.wikipedia.org/wiki/WAI-ARIA ↩
-
WebAIM Million 2026: 95.9% failure rate; same six categories for seven years. https://webaim.org/projects/million/ ↩ ↩2
-
OpenAI Atlas and Playwright MCP query the accessibility tree. https://nohacks.co/blog/how-ai-agents-see-your-website ↩
-
Accessibility snapshot ~4,000 tokens vs. screenshot ~50,000 tokens. https://matthewlarn.medium.com/why-ai-agents-are-changing-the-game-for-accessibility-8a6a59a71f6a ↩
-
CHI 2026 A11y-CUA study: Claude success 78% standard, 42% keyboard-only. https://www.sitepoint.com/how-ai-agents-are-making-accessibility-a-business-critical-development-priority/ ↩
-
Adrian Roselli on ARIA keyword-stuffing risk. https://adrianroselli.com/2025/10/openai-aria-and-seo-making-the-web-worse.html ↩
-
84% say accessibility is priority; 68% lack continuous testing. Applause 2025 survey. https://www.applause.com/blog/why-accessibility-is-the-infrastructure-for-ai-readiness/ ↩
-
Approximately 4,000–4,600 ADA web accessibility lawsuits filed in 2023. https://www.virtuosoqa.com/testing-guides/what-is-accessibility-testing ↩
-
Automated scanners detect only a fraction of real accessibility issues. https://polypane.app/blog/the-webaim-million-2025-solving-the-most-common-issues/ ↩
