Twenty Years of Filing Bug Reports Against the Web, and the Machines Finally Showed Up to Agree

The web's accessibility tree is a semantic representation of page content that browsers compute from the DOM. It was built over decades so screen readers could interpret interfaces designed for sighted users. In 2026, it turns out to be the same data structure that AI agents query when they need to understand a web page. The function call page.accessibility.snapshot() returns roles, names, and states. Not pixels, not CSS. Almost exactly what a screen reader has consumed for thirty years.¹

We spoke with Roz Labelledby, an accessibility engineer whose career spans the full arc from Microsoft Active Accessibility to the current moment, where agent infrastructure companies keep calling her about "machine-readability." She has been working on this problem since before most of their engineers were born.

She joined the call from her home office, browser DevTools open on a second monitor showing an accessibility tree. "I always have it open," she said. "It's like weather radar for someone who's been through a lot of storms."

You've been doing accessibility work for over two decades. When did you first notice that agents were consuming the same infrastructure you'd built for screen readers?

Roz: Before the agent people did. About three years ago, someone from an automation company asked me to consult on why their browser tool kept failing on certain pages. I pulled up the accessibility tree, showed them the missing labels, the divs cosplaying as buttons, and they looked at me like I'd performed a magic trick. I said, "This is what I do. This is what I've always done." They had independently arrived at the accessibility tree as their primary interface and had no idea there was an entire profession that had been maintaining and fighting over that tree for decades.

They'd reinvented the problem. Just hadn't reinvented the people.

Take us back to the earliest version of this. Before the web, before ARIA, what did machine-readability even look like?

Roz: Screen readers in the early days were essentially reverse-engineering the operating system. In Windows 3.1, they'd intercept GDI drawing calls, literally watching what the OS was painting on screen and trying to infer meaning from pixels.² Heroic, fragile work. Every OS update could break everything.

When Microsoft introduced MSAA in 1997, it was supposed to fix this by giving screen readers a proper API to query.³ But MSAA only worked if application developers chose to implement it. And most of them didn't, because, and I'm quoting the sentiment of roughly every product manager I've ever met, "that's a lot of work for a small user base."

The pattern was set right there. You can define the API, publish the spec, write the guidelines. None of it matters if the developer doesn't write the label.

Then the web arrived. HTML has semantic elements built in, so presumably things got better?

Roz: [laughs]

The early form spec, RFC 1866, didn't even have a <label> element.⁴ The name attribute was the transmitted key, not the text the user saw. So from day one, the visual presentation and the semantic meaning were decoupled. A sighted user could look at a form and know what each field was for because of its position next to some text. A screen reader saw an input floating in the void, connected to nothing.

And then Ajax happened.

The mid-2000s rich web application explosion.

Roz: That period nearly broke me. We'd spent years getting developers to use semantic HTML. Real headings, real lists, real buttons. Then overnight, everyone rebuilt their sites as JavaScript applications using div and span for everything. Collapsible trees, tabbed interfaces, dropdown menus, all constructed from generic elements with CSS making them look right and JavaScript making them act right. But to a screen reader? Silent. A tree widget built from nested divs is just text on a page.⁵

That's when the W3C started work on ARIA. The first public working draft came out in 2008, and it didn't become a full recommendation until 2014.⁶ Six years to get through the process, because the mapping problem was genuinely hard. Web semantics had to flow through browsers, through platform accessibility APIs, through assistive technology, across operating systems. Four layers. A failure anywhere in that chain produced silence.

ARIA was supposed to solve this. The 2026 WebAIM data suggests it... didn't?

Roz: I need to be precise here. Pages with ARIA present averaged 59.1 detectable errors. Pages without ARIA averaged 42.⁷ Now, that doesn't mean ARIA causes errors. Sites using ARIA tend to be more complex, more interactive widgets, more dynamic content, more places to get it wrong. But the deeper problem is real: ARIA done incorrectly is actively worse than no ARIA at all.

Here's why. Before ARIA, a custom dropdown built from divs was invisible to a screen reader. Useless, but honestly invisible. With incorrect ARIA, that same dropdown announces itself as a combobox and then does nothing.

Agents hit the same wall now. An agent reads role="button" on a non-functional div, clicks it, reports success. The semantic declaration created a door that doesn't open.

95.9% of the top million home pages still fail basic accessibility checks. After all this work. How do you process that?

Roz: Poorly.

Fair.

Roz: The six most common errors haven't changed in seven years. Low contrast text. Missing alt text. Missing form labels. Empty links. Empty buttons. Missing document language.⁸ A first-year student could fix any one of them. The problem was never that we didn't know what to do. Machine-readability isn't a feature you ship. It's a discipline you maintain. Every redesign, every framework migration, every new component library can reintroduce the same errors. You need someone checking. You need someone who cares.

And here's what keeps me up at night now: AI code generation tools are producing markup at a speed no human can audit. A developer who understands HTML will notice a missing aria-label. Someone pasting generated code into production won't.⁹ The volume of new pages is accelerating. The rate of semantic maintenance is flat.

So agents arrive, they converge on the accessibility tree as their primary interface, and they find...

Roz: They find what I've been filing bug reports about for twenty years. Missing labels. False declarations. Buttons that aren't buttons. Live content that doesn't announce itself. The accessibility tree is only as good as what developers put into it. And what developers put into it, on 96% of the web, is incomplete.

What I keep telling the agent infrastructure people, the same thing I told screen reader vendors in 2004, and browser teams in 2010, and framework authors in 2016: you cannot solve this downstream. You can't build a smarter consumer of bad semantic data. You can make the consumer more resilient, sure. You can fall back to pixel inference, which agents can do and screen readers can't.¹⁰ But the underlying problem remains. The page doesn't say what it means.

Do you find any satisfaction in being vindicated?

Roz: [long pause]

But I'll say this. For the first time in my career, when I tell a product team that their unlabelled form inputs are a problem, they don't just hear "accessibility compliance." They hear "your checkout flow breaks when an agent tries to use it." Same fix. Same <label>. Different motivation.

I'll take it.

Footnotes

1. TinyFish KB, "Web Agent Stack," wiki/web-agent-stack.md; see also "The Accessibility Tree is the New API," https://dev.to/ssmancha/the-accessibility-tree-is-the-new-api-1hm4 ↩

2. Mozilla Archive, "History of Software Accessibility," https://www-archive.mozilla.org/access/today ↩

3. Wikipedia, "Microsoft Active Accessibility," https://en.wikipedia.org/wiki/Microsoft_Active_Accessibility ↩

4. Pressbooks, "The Evolution of Web Accessibility," https://pressbooks.library.torontomu.ca/pwaa/chapter/the-evolution-of-web-accessibility/ ↩

5. W3C WAI-ARIA Primer (February 2008), https://www.w3.org/TR/2008/WD-wai-aria-primer-20080204 ↩

6. WAI-ARIA 1.2 became a W3C Recommendation on June 6, 2023; the initial working draft was published September 2008. https://www.w3.org/TR/wai-aria-1.2/ ↩

7. WebAIM Million 2026 Report, summarized via https://www.nexerdigital.com/news-and-thoughts/the-webaim-million-report-2026-what-it-tells-us/ ↩

8. WebAIM Million 2026 Report, https://prioritypixels.co.uk/insights/web-accessibility-is-getting-worse-according-to-the-2026-webaim-million-report/ ↩

9. Analysis from https://wecreate.digital/blog/web-accessibility-is-going-backwards-the-2026-webaim-million-report-tells-us-why/ ↩

10. TinyFish KB, "Assistive Agents and Accessibility," wiki/assistive-agents-and-accessibility.md ↩