Why AI Agents Write Inaccessible Code

An AI coding agent generates a new checkout button in eight seconds. It renders perfectly: right color, right position, right label. But screen readers don't see what's on screen. They rely on the code to tell them what each element on a page is. If a button only looks like a button and isn't coded as one, a screen reader can't recognize it. The code ships without anyone noticing, until a screen reader user tries to check out and can't find the button at all.

AI coding agents aren't careless. They write inaccessible code for two bigger reasons. First, they learned to code from the web, and most of the web isn’t accessible, so they reproduce the same mistakes at scale. Second, they can only check what they can test: whether the code complies and whether the page looks right. AI can’t use a page the way a screen reader does, so the issues that matter most go unnoticed. 

Those gaps show up as four specific, repeatable failure patterns, and all four are fixable before the code is ever written.

Do AI Coding Agents Actually Produce More Accessibility Violations?

Not significantly more, but not meaningfully either. In AudioEye research, sites built by five leading AI coding tools averaged 55 accessibility issues per page, only slightly better than the 62 issues per page found on the average website. And every AI-built site still failed Web Content Accessibility Guidelines (WCAG) Level A, the most basic accessibility standard. 

That small improvement can create a false sense of compliance. AI-generated pages often look polished and modern, and teams may assume the code underneath is just as sound. It usually isn’t. In the same AudioEye study, 91% of issues were medium or high severity, and many of them affected interactive elements like buttons, forms, and navigation, where a single failure can stop a user from completing a task.  

Why AI Coding Agents Generate Inaccessible Code

1. The Training Data is Mostly Inaccessible Code

An AI coding agent learns to write code from the public web, and the public web is mostly inaccessible. AudioEye’s 2026 Digital Accessibility Index found an average of 62 accessibility issues per page across the sites it scanned. An agent trained on that corpus learns inaccessible patterns as the default, not the exception, because most of its training examples look like that.

2. Agents Test the Code, but Don’t Use Assistive Technology

AI agents can confirm that the code runs and that a page looks right. What they can’t do is use the page the way a person with a disability would, with a screen reader or keyboard alone. A dropdown can open perfectly on screen and still be impossible to use without a mouse, for example. Because agents never experience the page that way, those problems never show up as failures.

3. Accessibility Requirements are Rarely in the Prompt

A developer asks an AI coding agent for a dropdown, a modal, or a form. They rarely ask for an accessible dropdown, an accessible modal, or a labeled form. The agent builds what was asked for. If accessibility wasn’t in the prompt or the surrounding context, nothing is telling the agent to include it.

Even when accessibility is part of the request, agents struggle to deliver it. In AudioEye’s study of AI coding tools, where each tool was specifically asked to build an accessible site, 12 of the 15 sites included a “skip to main content” link. Not one of those links actually worked. The agents knew to add the feature, but not how to make it actually function.

Stylized laptop screen with various error messages on the screen next to the accessibility symbol; a magnifying glass is over one of the accessibility errors.

The Four Failure Patterns that Show Up Most

AI coding agents often build accessibility features that look right but don't actually work. AudioEye reviewed 15 sites built with AI coding agents, scanning 288 pages and testing how each site behaved in use. These four problems came up most often, and all four are WCAG 2.1 Level AA failures.

1. Error Messages that Screen Readers Can’t Hear

When someone submits a form with a mistake, an error message appears on screen. But the agent doesn’t connect that message to the field it’s about, so a screen reader never announces it. So when the user submits the form, the page rejects it, and the user has no idea why. The only way to find the problem is to go back through every field, one at a time.

2. Skip Links that Don’t Actually Skip

A "skip to main content" link lets keyboard users jump past the menu to the main part of the page. Agents often add these links, but they only scroll the page. The keyboard stays where it was, so the next key press takes the user right back to the menu they were trying to skip.

3. Headings Used for Size Instead of Structure

Screen reader users navigate long pages by jumping from heading to heading, much like skimming a table of contents. That only works if headings follow a logical order. Agents often choose heading levels based on how big the text should look, so the page's outline no longer matches how the content is actually organized.

4. Pop-Up Panels that Keyboard Users Can’t Reach

When a cart or search panel opens, keyboard focus should move into it. Agents often leave focus on the page behind it instead. The panel is open on screen, but a keyboard or screen reader user keeps moving through links underneath it that they can't see, with no sign that the panel ever opened.

Notice what these have in common. The agent builds the skip link. It built the error state. It built the dialog. But what it missed is the part that makes the feature work for a user with disabilities. That part is invisible on the page, so it’s easy to miss.

What This Looks Like in Practice

The skip link is the clearest example. Twelve of the fifteen sites in our study built one, and all twelve got it wrong in the same way: 

<a href="#main" class="skip-link">Skip to main content</a>

...

<div id="main">

  <!-- page content -->

</div>

The link exists, the target exists, the IDs match. But finding those pieces in the code doesn’t tell us whether the feature works for the people who need it. 

A skip link should let keyboard users bypass the header and continue navigating from the main content. Browsers can support that behavior even when the destination is a non-focusable <div>, so this markup alone isn't proof of failure. The real test is what happens after activation: does the next Tab reach the main content, or does the user still have to work through the navigation?

This is the version that works:

<a href="#main" class="skip-link">Skip to main content</a>

...

<main id="main" tabindex="-1">

  <!-- page content -->

</main>

The two changes serve different purposes. The <main> element identifies the page's primary content as a landmark for assistive technology. The tabindex="-1" attribute makes that destination focusable without adding another stop to the normal Tab sequence. The skip link also needs to be visible when it receives keyboard focus, and its behavior should be tested with both a keyboard and a screen reader.

That's the gap this example illustrates: AI-generated code can include the recognizable parts of an accessibility feature without establishing that the experience works. A code review can confirm that a skip link is there. Only testing can confirm it actually helps someone skip the navigation.

Woman sitting in front of a computer screen showing a website with various errors on it holding a magnifying glass. A gear shaft with the accessibility symbol is to the left of the computer.

How to Make AI-Generated Code Accessible Before it Ships

Fixing accessibility while the code is being written is far cheaper than fixing it after launch, because agents work from the existing codebase. One inaccessible button is a ten-second fix, but an inaccessible button that ships becomes the pattern for the next twenty components. Post-launch means fixing the same mistake once for every place it propagated.

There are three approaches, from least to most reliable.

• Prompting: Asking for accessible output helps. It is also unreliable: the agent has no way to verify its result against assistive technology behavior, and it regresses the moment the instruction falls out of context. While useful, it's not dependable.

• Linting: Accessibility linters reliably catch a real subset of issues, flagging a missing alt attribute or insufficient contrast. What they cannot do is press Tab. Most of the behavioral failures above don't appear in a scanner's default output, because the code is valid and only the behavior is missing.

• Rules in the agent’s context: The durable fix is to make accessibility part of what the agent knows as it writes. The agent isn't failing because it's incapable of semantic HTML; it's failing because nothing in its context makes accessibility part of a correct output. The AudioEye SDK MCP connects the agent to AudioEye Intelligence, so it can find an issue, apply a proven fix, and rescan to confirm it's resolved, with developers reviewing and approving every change. Because that expertise lives in the agent's context rather than the prompt, it holds across sessions and developers instead of depending on who remembered to ask.

What Generation-Time Fixes Cannot Catch

Rules fix what is rule-shaped: whether a button has an accessible name, whether that name tells the user what the button does, whether that judgment is a call, and whether a checkout flow is completable with a screen reader. These are questions that can only be answered by completing them with a screen reader. 

The boundaries beyond that are worth being explicit about. Rules will not fix the inaccessible components already in your codebase, which agents will continue to imitate because that is what they pattern-match against. They will not fix decisions made before code, since insufficient color contrast, motion without a reduced-motion alternative, and touch targets sized too small are design problems, and the agent implements the design it is given. 

They will also not fix content authored outside the codebase. Things like alt text written in the CMS, PDFs uploaded to the site, and third-party embeds are all outside the agent’s reach.

Build it Right, then Verify it Works

AI coding agents are not going to stop writing your front-end, and they shouldn’t have to. But our research shows what happens when they work without accessibility expertise: across the 15 AI-built sites we reviewed, 306 distinct issues appeared more than 59,000 times. The same mistakes, repeated page after page. That’s not an argument against building with agents, but rather an argument for telling the agent what “accessible” means before it writes, rather than discovering what it got wrong after launch.

The AudioEye SDK MCP does that. It connects the agent your developers already use, Claude Code, Codex, GitHub Copilot, and Cursor, to AudioEye’s accessibility data set: 14 years of work, over a million human reviews across more than 100,000 sites, with 2.5x more issues found than other tools. With our SDK MCP, AI coding agents stop inferring what "accessible" means and work directly from a source that does. 

It also closes the loop before anything ships. The SDK MCP scans the code, suggests a fix, then developers confirm the issue is actually resolved before the code is committed. Every fix comes back for approval rather than being applied silently, so developers stop hand-writing accessibility code and start reviewing it.

Ready to see what your AI-generated pages are actually shipping? Talk to our experts about AudioEye’s SDK MCP.