Study · Updated July 2026
How accessible is AI-generated UI?
We ran a deterministic design audit over 123 public frontends built by AI coding tools. The tools handle what you can see. They miss what you cannot see in a screenshot.
Where the gaps are, by category
Share of the 123 frontends with a finding in each category, split into serious errors and lower-severity warnings. Only three categories produce errors serious enough to stop code from shipping. Accessibility is by far the largest.
What actually breaks
Accessibility is the biggest category, so here is what specifically failed inside it, and how often across the 123 frontends. Every one is a small, known fix.
| What breaks | Frontends | The fix |
|---|---|---|
| No skip-to-content link | 95% | Keyboard users tab through the entire nav on every page. Add one hidden “skip to content” link at the top. |
| No main landmark | 53% | Screen readers can’t jump past the nav to the content. Wrap the page body in a main landmark. |
| Form inputs with no label | 49% | A screen reader can’t say what the field is for. Tie a visible label to every input. |
| Broken heading structure | 42% | Multiple or missing h1s break the outline screen readers navigate by. Use exactly one h1, then step down. |
| Links used as buttons | 36% | A link styled as a button isn’t operable as one by keyboard. Use a real button for actions. |
| Skipped heading levels | 29% | Jumping from h2 to h4 breaks the document outline. Step down one level at a time. |
| Icon buttons with no name | 19% | An icon-only button just announces as “button.” Give it an aria-label. |
What this does to the person using it
These aren’t abstract scores. Each failure has a direct cost for someone using a keyboard or a screen reader. These are the users an AI tool can’t see in a screenshot.
- 95%No skip-to-content link. A keyboard user tabs through every nav item, often 15 to 20 stops, to reach the content on every page.
- 49%Form inputs with no label. A screen reader reaches the field and can only say “edit text.” It gives no clue what to type.
- 19%Icon buttons with no name. The close, menu, and search controls all announce as just “button.” Identical, and meaningless.
What you see
Looks perfectly usable.
What a screen reader hears
None of it says what it does.
Errors per project: clean to severe
Three in four frontends ship at least one serious error. The spread is wide: about a quarter are clean, most land at one to five, and roughly one in six carry eleven or more. The worst had 194.
Method, and what we actually audited
We searched public GitHub for repositories that self-identify as AI-generated (v0, Lovable, bolt, and similar), across 150+ accounts. Of 165 cloned, 123 had an analysable frontend and form the sample. Every one was checked with the same deterministic tool: no model, no network, no judgement, so the same repository yields the same numbers every time. The sample is large enough that the headline rates hold to within two points if the ten worst projects are dropped.
No model in the loopSame input, same outputFrontend-only denominator
You don’t have to take our word for any of it. See all 123 repositories and their scores → Open any of them on GitHub and check.
“Accessibility error” here means a structural markup failure: unlabelled inputs, non-semantic buttons, missing landmarks, skipped headings, a stricter, narrower definition than a full manual review. The corpus skews toward landing pages, portfolios, and small apps.