Study: AI coding tools do not write accessible code
A new study reveals that the most popular AI coding tools do not meet basic accessibility standards when creating websites.
AudioEye gave five coding AI tools from OpenAI, Anthropic, Google, xAI and Lovable the same brief: build a news and media site, an online store and a financial services site that met the Web Content Accessibility Guidelines 2.2 Level AA, the global standard for accessibility compliance.
The biggest takeaway: All 15 sites failed to meet Level A, the most basic level of this standard. Most teams assume that code ships with accessibility built in. These sites did not.
Testing across the 15 sites found 306 distinct accessibility issues, appearing more than 59,000 times across the pages. A single mistake in a navigation menu or form field repeats on every page that uses it.
The amount of code AI is writing makes this urgent. DX(opens in a new tab), which tracks engineering data across more than 400 companies, put AI-authored code at 51.9% of the total in mid-2026, up from 24% two quarters earlier. Teams are shipping AI-generated code faster than manual reviews can keep up with.
In AudioEye’s companion survey of developers and business leaders, 81% said they were confident the AI-generated code on their site meets accessibility standards.
INSIGHT 1
AI-built sites are nearly as inaccessible as the general web
The AI-built sites averaged 55 accessibility issues per page. The average page in the 2026 Digital Accessibility Index has 62. That put AI-built pages close to the average page on the web.
The reason is simple. These tools learned to code from the existing web, and that web is largely inaccessible. In WebAIM's 2026 scan(opens in a new tab) of the top one million homepages, they found the average site had 56.1 errors per page, which puts the AI-built sites in the study on par with 55. The decrease in homepage accessibility in 2026 is the first decline in six years, reversing a run of gradual improvement. WebAIM attributes the reversal in part to AI-assisted coding.
Asked to build accessible code, every tool reproduced the inaccessible practices it learned from the web. Five independent tools broke the same components in the same ways. Switching tools gets you a different version of the same problem.
Most developers are not accessibility experts, so they may trust the model to get it right. But the models don’t have that expertise either. Development teams trust the output without testing it, allowing failures to ship.
INSIGHT 2
91% of the issues on AI-created sites were medium and high severity
A high-severity issue either prevents a person from finishing a task or makes it much harder to do so. Thirty-three percent of the issues found block the task outright. Someone using a screen reader (or AI agents) cannot check out, submit a form or reach the content they came for.
These failures showed up on nearly every build. Thirteen of the 15 sites shipped at least one issue that completely blocks a task.
The same problems showed up on-site after site: links with no description, buttons a screen reader cannot identify and form fields with no labels. Many of the unlabeled buttons and fields sat right where customers take action, like checkout buttons and login forms.
Plaintiffs' firms cite these exact failures in most accessibility demand letters, because they stop real people from buying, signing up, or getting help. Someone who uses a screen reader reaches the checkout button and hears nothing. Someone navigating by keyboard opens the cart but cannot get into it. They do not file a complaint or contact support.
That is the part most teams never see. The revenue may be gone before anyone knows there was an issue, and the first signal is often a letter from a law firm. By then, the costs have compounded: the customers who left, the legal fees and the engineering time pulled off the roadmap to address claims about code that shipped months earlier.
INSIGHT 3
AI builds the feature but skips the part that makes it work
Every accessibility feature has two parts: the code that describes it, and the behavior that code promises. In the study, the AI tools often wrote the code, but the behavior wasn’t always present.
Take skip links, which let someone using a keyboard or screen reader jump past the navigation straight to the content. It needs a link and a target that can receive keyboard focus. Twelve of the 15 sites had the link, but not one had the target wired. All 12 broke the same way. The page scrolls, but focus never moves. The person is still at the top of the navigation, tabbing through every menu item.
Nearly half the issues found cannot be seen by reading the code. They appear only when someone uses the page: opening a menu, tabbing through a dialog, submitting a form with an error or viewing the site at phone width.
Reading the code will not show whether focus moves, whether a keyboard can close a dialog, or whether a screen reader announces a form error. Someone has to open the page and test it with the same assistive technology a customer uses. Automated accessibility tools cover code at scale, while expert testing covers behavior. A team that reviews only the code never checks the part that actually prevents people from using the site.
INSIGHT 4
The e-commerce sites had 3 times as many issues
The AI-built stores averaged 174 accessibility issues per page, compared with 55 across the AI-built sites overall.
Online stores are not usually much worse than other sites. In the 2026 Digital Accessibility Index, e-commerce pages average 65 issues against 62 for pages overall, a difference of about 5%. When AI built the stores, they came out with more than three times as many issues as the other sites it built. AI did not fail evenly. It failed hardest on the sites where people spend money.
A store has more moving parts than other sites. Shoppers filter products, search, add to a cart and pay. Every step is something a person has to click, type into or reach with a keyboard. If a filter cannot be reached by keyboard, the shopper never finds the right product. If a screen reader reads the cart button as blank, they cannot buy it.
Those are also the pages that get sued. The 2026 Web Accessibility Litigation Report found that 78% of accessibility lawsuits target e-commerce, and that filings have doubled since 2020. AI is building the web’s most-sued pages, often with serious accessibility flaws.
Accessibility has to scale with AI
Teams are confident in their AI-generated code, even as complaints climb. In a companion survey of developers and business leaders, 81% said they were confident that the AI-generated code on their sites met accessibility standards. However, 46% had received an accessibility complaint, demand letter or lawsuit, and 71% of those respondents said that AI was involved in coding the page that received the complaint.
AI can build a website in an afternoon. It cannot reliably tell you whether a person can use it, because it doesn’t have the capability to check.
Teams are shipping AI-built pages faster than their review process can keep up. When companies cannot review pages at that pace, they risk shopping pages that no one has checked for accessibility and those pages can draw demand letters.
Scaling takes two things. Teams needs to check every page on the site, not just the homepage. Two-thirds of AI search traffic now lands on interior pages, and 64% of accessibility claims in 2025 cited issues on those pages. Scaling also requires the accessibility expertise that general-purpose AI tools lack.
AI and accessibility are not opposing forces. AI supplies the speed. Accessibility expertise at scale supplies compliance requirements and reduces legal risk. Used together, they can build a web that works for everyone and that teams can actually trust.
This story was produced by AudioEye and reviewed and distributed by Stacker.
