The prompt is almost embarrassingly simple. “Build me a website for a small bakery. Make it accessible.” Every one of the twenty AI website builders we tried said yes, in the warm, unhesitating way these tools say yes to everything. Seconds later, out came the sites: hero images, menu sections, contact forms, footer links. They looked like websites. They had the confident, slightly generic polish of a template that went to a good school.
Then we looked closer. Buttons that were actually divs — clickable to a mouse, invisible to a keyboard. A form with labels floating as placeholder text that vanishes the moment you start typing. Alt text that described the hero image as “image” or, worse, as a small poem about artisanal bread that a screen reader user never asked for. Contrast ratios that failed by margins no human eye would catch but any automated audit flags instantly. Every site, in its own way, was a plausible imitation of accessibility rather than the thing itself.
This is the part that’s easy to get wrong, so it’s worth saying plainly: the tools are not lying exactly, and they are not broken. They are doing precisely what they were built to do. They learned from the web as it is, and the web as it is fails accessibility almost everywhere.
The median site is the message
Each year, WebAIM audits the top one million home pages for automatically detectable WCAG failures. The 2026 edition found them on 95.9% of pages — up from the year before, reversing six years of slow improvement. That figure needs a caveat: automated testing catches only a subset of accessibility problems, so it counts pages with at least one machine-detectable error, and true conformance is certainly worse than the remaining 4.1% suggests. But the shape of the failure is what matters here. The same six categories — low-contrast text, missing alt text, unlabeled form inputs, empty links, empty buttons, missing document language — have topped the list for seven consecutive years and account for 96% of all detected errors. The average home page now contains over 1,400 elements and an average of 56 detectable errors.
In other words, the training data for every code-generating model on earth is a corpus in which the median page is inaccessible in boring, predictable, well-documented ways. When a model generates a button as a div, it is not hallucinating. It is reproducing the statistical center of the web. The failures in our twenty bakery sites were not random; they were the same failures WebAIM finds at scale, delivered fresh.
There is a deeper asymmetry underneath this. The web is full of compliance language — accessibility statements, WCAG checklists, earnest blog posts about inclusive design, the word “accessible” deployed as an adjective of praise. What the web is not full of is compliant markup. A model trained on both learns the vocabulary fluently and the practice barely. So it can write you a beautiful accessibility statement for a site that a screen reader can’t navigate, and in our testing, several effectively did. The promise is in the training data. The fulfillment is not.
The one direct study of this that exists so far found exactly what you’d predict. Researchers at the 2024 ACM Web for All conference generated 88 websites with ChatGPT and found 84% had accessibility issues — hundreds of contrast failures, hundreds of structural problems, dozens of missing alt attributes. When asked to fix its own output, the model remediated most violations but only 57% of unlabeled-button issues and zero percent of checkbox-labeling problems. Even the repair loop has blind spots, and they cluster in precisely the places where the training data is thinnest.
Faster than the fix
None of this would be urgent if the output were slow. It is not slow. The economics of web publishing have quietly inverted: the cost of generating a page has collapsed toward zero, while the cost of making a page accessible — real accessibility, the kind that involves testing with actual assistive technology and actual disabled users — has not moved at all. Remediation is still artisanal work. Generation is now industrial.
That gap is the story. Every remediated site is now competing for attention against a flood of new ones that were never accessible to begin with, and the flood is winning by default. The WebAIM numbers already hint at the direction of travel: after years of incremental improvement, errors per page jumped 10% in a single year, and page complexity grew by more than a fifth. The web is getting bigger and worse at the same time, and AI generation is pouring into exactly that current. A June 2025 New York City Bar Association report on digital accessibility put the mechanism in one sentence: “AI cannot solve for accessibility if it was never trained to recognize it.”
The accessibility professional Joe Dolson ran a version of our experiment before we did, building a site entirely with AI on his video series last year. His verdict was measured: the result was “far from the worst” he’d seen, full of “very predictable mistakes,” and not sufficient on its own. That is, if anything, the optimistic reading. Dolson is an expert who knew what to look for. The people now prompting sites into existence at scale are, by and large, not checking, because the whole pitch of these tools is that you don’t have to.
There’s a temptation, writing this, to frame it as a problem of model quality — to say the next generation will be better, that someone will fine-tune on accessible code, that the builders will add a checker. Maybe. But notice what that framing concedes: that accessibility is a feature to be added rather than a property of the corpus. The models are a mirror. They have shown us, with unusual clarity, what the web actually is beneath its accessibility statements — and the uncomfortable implication is that “generate me an accessible website” was never a prompt problem. It was always a supply problem. You cannot sample your way to a world the data doesn’t contain.
The bakery sites are live now, presumably, some of them. They look lovely. The bread is probably fine.