Fix-at-source hasn't closed the accessibility gap. Most AI coding tools are only making it wider.

Some teams try to shift accessibility left: catch problems at the source, in the code, before anything ships, so every new page is accessible from day one. The goal is straightforward. Getting there is not, and it only gets harder as sites grow bigger and change faster.

To help shoulder the load, teams are increasingly turning to AI coding agents. In a survey of 10,000 developers, 90 percent said they use at least one AI tool at work, and 74 percent have adopted a dedicated AI coding tool(opens in a new tab). Even the companies building the models are living this shift: Anthropic said its engineers now ship 8x as much code per quarter(opens in a new tab) as they did from 2021 to 2025.

But there's mounting evidence that AI coding tools are making accessibility worse, not better.

WebAIM's 2026 report(opens in a new tab) noted that the average number of accessibility issues on the world’s top one million home pages increased for the first time in years, jumping 10.1 percent from 2025. The report names “automated or AI-assisted coding practices” as a likely reason for this year's jump in errors, along with more complex pages.

Fix-at-source and AI-assisted coding are both falling short, and not for the same reason.

Fix-at-source struggles to keep pace

Shifting accessibility left only addresses new code and content, not what's already live on a site. Most teams are sitting on years of pages that were never built with accessibility in mind, and shipping clean code today doesn't undo that.

AudioEye's 2026 Digital Accessibility Index found the average page has 62 issues that automated tools alone can detect(opens in a new tab), not including the ones that only expert testing can uncover. Multiply that across a site with a few thousand pages, and fix-at-source alone can't realistically close the gap, no matter how disciplined the team is going forward.

Going forward isn't easy either. Catching issues at the source depends on a team having enough developer time and accessibility know-how to check new code before it goes live, and most teams don't. Accessibility experts are hard to find and expensive to hire. Developer time is the most fought-over resource on any team, and accessibility work has to compete with everything else on the roadmap. And even when a team does catch up, the job doesn't stay finished: every new page, every redesign, every campaign is another chance to introduce the same issues all over again.

A stylized person inside a cracked sphere surrounded by digital screens with icons and text, symbolizing digital disruption or breakthrough.

AI was supposed to close the gap. It didn't.

The hope was simple: if AI helps developers ship faster, some of that time saved should flow back into everything else, accessibility included. That's not what's happening.

These tools are trained on the web as it already exists, and most of the web still fails basic accessibility checks. They weren't purpose-built to fix accessibility. They were built to write functional code, fast, and they learned that job from a web full of missing labels, broken keyboard navigation, and mislabeled forms. A developer can ask one of these tools to build a new checkout flow, and it will, in seconds. What it can't do is put that flow in front of a real screen reader user and watch where it actually breaks, because that kind of testing was never part of its training. It reproduces what it learned, just much faster and at a volume no team of developers could match by hand.

The volume makes the problem worse, not just more visible. When a team's code output multiplies and accessibility review stays flat, the share of new code that actually gets checked shrinks every quarter. More output, same review capacity, a widening gap.

The fix needs both sides

Fix-at-source runs out of people. AI coding runs out of judgment. Closing the gap means building something that runs out of neither.

The best version of this looks different: automation and AI working every hour of every day, generating and checking code faster than any person could, backed by the kind of deep accessibility expertise that today only comes from people who know what a screen reader user actually needs from a checkout flow, not just what passes an automated check.

Speed without that expertise just reproduces the same mistakes faster. Expertise without that speed can't keep up with how much code ships every day. Put them together, and you get what neither can do alone: accessibility that moves at the same pace as the web itself.

Stylized projection screen with a man standing and pointing at the accessibility icon and a sitting woman holding a bullhorn next to the screen. A large accessibility icon is also on the left-hand side of the screen.

Better data won't fix this by itself

There's a fair question here: won't this fix itself over time? As more accessible code gets written and used to train these tools, shouldn't AI get better on its own, the way it has at almost everything else?

Maybe, eventually, for the easy cases. But most of the code these models learn from is still inaccessible, so that won't change fast. And the barriers that matter most, like a broken checkout flow or a custom component nobody tested, are exactly the rare, tricky cases a model trained on averages struggles to resolve. Waiting for training data to fix this repeats a mistake we've already made: hoping speed alone would eventually produce accessibility. It hasn't yet, at any layer.

The fix has to move to the moment the code gets written, whoever or whatever is writing it. That means real accessibility expertise built directly into the tools teams already use, not added afterward as a scan or an audit.

We're working on what that looks like, and we'll have more to share this fall. For now, ask yourself this: as more of your code gets written by AI, is accessibility expertise part of that process, or still something you're hoping to catch later?

Right now, somewhere, a developer is watching an AI assistant generate a new checkout flow in under a minute, then moving on to the next ticket. Somewhere else, a person using a screen reader is still looking for the button that submits it. Closing that gap is the work ahead.