How to Audit AI-Generated Websites for Accessibility Compliance

AI website builders have gone from novelty to default. Tools like Framer AI, Wix ADI, Durable, and the growing stack of GPT-powered page generators can spin up a full landing page in under 90 seconds. The output looks polished. The problem is that "looks polished" and "usable by a screen reader" are two very different things, and the gap between them is where lawsuits live.

Here is the surprising part: in 2023, U.S. plaintiffs filed over 4,600 web accessibility lawsuits under the ADA, and a large share targeted small and mid-size businesses, not just the Fortune 500. Independent testing by WebAIM on the top one million homepages found that 95.9% had detectable WCAG failures, averaging roughly 50 errors per page. AI-generated sites are not exempt. In my own testing, they often produce cleaner markup than hand-coded sites in some areas and far worse markup in others, like missing form labels and decorative images that get announced as content.

This guide walks you through a complete AI website accessibility audit from first scan to signed-off fixes. You will learn which automated checks catch 40% of issues, how to find the other 60% by hand, how to interpret the results, and how to build accessibility into your AI generation workflow so you are not re-auditing every week.

Key Takeaways

• Automated scanners catch roughly 30–40% of WCAG issues. Manual keyboard and screen-reader testing is non-negotiable for the rest.
• AI builders commonly fail on alt text, form labels, color contrast, heading order, and focus states. These five account for most violations.
• Aim for WCAG 2.1 Level AA as your compliance baseline. It is the standard most regulations reference.
• Run a layered audit: automated scan, keyboard-only pass, screen-reader pass, then a contrast and zoom check.
• Re-generated AI content silently breaks accessibility, so bake audits into your deployment checklist, not just launch day.
• Document everything. A dated audit log is your best defense if a complaint ever lands.

Why AI-Generated Websites Fail Accessibility by Default

AI builders optimize for what they can measure: visual layout, copy that reads well, and components that render without errors. Accessibility lives in the parts users never see directly, which is exactly where machine-generated output tends to cut corners.

Three structural reasons explain most failures:

• Training bias toward appearance. Models learn from scraped sites, and most scraped sites are already inaccessible. The AI faithfully reproduces bad patterns.
• No semantic intent. When you prompt "add a hero section with a button," the model does not know whether that button submits a form, opens a modal, or navigates. It guesses, often choosing a styled <div> over a real <button>.
• Generated images and icons. AI-produced imagery almost never ships with meaningful alt attributes. Decorative SVG icons get read aloud as "image" or worse, their raw file names.

The result is a site that passes a casual glance and fails the moment someone navigates with a keyboard or a screen reader. If you also had the AI write the backend, review our guide on how to verify AI-generated code before merging it to production alongside this one.

What WCAG 2.1 AA Actually Requires

WCAG organizes success criteria under four principles, easy to remember as POUR:

• Perceivable: text alternatives, captions, sufficient color contrast (4.5:1 for normal text).
• Operable: full keyboard access, visible focus, no keyboard traps, enough time to read.
• Understandable: predictable navigation, labeled inputs, clear error messages.
• Robust: valid markup that works across assistive technologies.

The 5-Layer AI Website Accessibility Audit Framework

I run every site through five layers, in order. Each layer catches a distinct class of problem, and skipping any one leaves a visible hole. Here is the full walkthrough.

Layer 1: Automated Scanning (catches ~35%)

1. Install the axe DevTools browser extension (free tier) or WAVE by WebAIM.
2. Open your AI-generated page in Chrome. Launch DevTools, go to the axe or Lighthouse tab, and run a full-page scan.
3. Record the raw count. A fresh Framer or Wix AI page typically returns 12–30 violations on the first pass.
4. Export the report as CSV so you have a dated baseline.
5. Sort violations by impact: critical and serious first, then moderate.

Lighthouse scores accessibility out of 100. Treat anything below 90 as failing, but never treat 100 as "done." Lighthouse itself warns that it only tests a subset of criteria.

Layer 2: Keyboard-Only Navigation (catches operability failures)

1. Unplug your mouse or set it aside. Use only Tab, Shift+Tab, Enter, Space, and arrow keys.
2. Tab through the entire page. Confirm every link, button, and form field receives focus in a logical order.
3. Watch for a visible focus indicator. AI builders frequently strip the default outline with outline: none and never replace it.
4. Test every interactive element. Can you open the mobile menu, close the cookie banner, submit the form, and dismiss the modal without a mouse?
5. Flag any keyboard trap, where focus gets stuck inside a widget and Tab will not escape.

Layer 3: Screen-Reader Testing (catches perceivability failures)

You do not need expensive software. Use NVDA (free, Windows), VoiceOver (built into macOS, press Cmd+F5), or Narrator on Windows.

1. Turn on the screen reader and close your eyes or dim the monitor.
2. Navigate by headings (H key in NVDA). Confirm headings describe content and follow a logical h1 → h2 → h3 order with no skipped levels.
3. Navigate by links. Listen for vague anchors like "click here" or "read more" with no context.
4. Reach every image. Decorative images should be silent (empty alt=""); meaningful images should describe their content.
5. Fill out any form. Each field should announce its label, its required state, and any error.

Layer 4: Color Contrast and Visual Checks

1. Use the axe or WAVE contrast tool, or the standalone WebAIM Contrast Checker.
2. Verify body text hits 4.5:1 and large text (18pt+ or 14pt bold) hits 3:1.
3. Check hover and focus states too. AI themes love low-contrast gray-on-white placeholder text.
4. Confirm no information is conveyed by color alone (for example, a red field border with no error text).

Layer 5: Zoom and Reflow

1. Zoom the browser to 200%. Content must remain readable without horizontal scrolling.
2. Set viewport to 320px wide and confirm the layout reflows cleanly.
3. Watch for text clipped inside fixed-height containers, a classic AI layout bug.

A Worked Example: Auditing a 6-Page AI-Generated Site

Let me make this concrete. A client handed me a 6-page site built with an AI generator in an afternoon: home, about, services, blog index, a single blog post, and a contact page. Here is what the audit found and how long it took.

Layer 1 (automated), 20 minutes total. axe DevTools returned 71 violations across all six pages. The breakdown:

• 23 images with missing or empty-but-meaningful alt text
• 14 color-contrast failures, mostly a light-gray navigation and footer
• 9 form fields on the contact page with no associated <label>
• 6 skipped heading levels (jumping from h1 to h4)
• 19 miscellaneous: duplicate IDs, missing lang attribute, non-descriptive link text

Layer 2 (keyboard), 25 minutes. The mobile hamburger menu could not be opened by keyboard at all. Focus outlines were globally disabled. The contact form submit button was a <div> with a click handler, so it was completely unreachable by keyboard.

Layer 3 (screen reader), 40 minutes. Two hero images announced their file names, like "hero-final-v3-compressed." The blog post had no h1. Form errors appeared visually but were never announced.

Totals. Automated tools caught 71 issues. Manual testing surfaced 14 more critical ones that no scanner flagged, including the unreachable submit button, arguably the single most serious failure on the site. That is the 35% versus 65% split in action.

Remediation time: about 6 hours. The fixes were unglamorous: real <button> elements, proper labels, a darker gray, descriptive alt text, and a visible focus style. The site went from a Lighthouse accessibility score of 61 to 98, with the remaining 2 points representing checks Lighthouse cannot automate.

Automated vs Manual vs Overlay Tools: What Actually Works

There is a lot of noise in this space, especially from "accessibility overlay" vendors promising one-line compliance. Here is an honest comparison of the three approaches.

Approach	Coverage of WCAG issues	Cost	Legal protection	Best for
Automated scanners (axe, WAVE, Lighthouse)	30–40%	Free to low	Partial, as evidence of effort	Baseline and regression checks
Manual testing (keyboard + screen reader Cover image: Innovate Maryland Emerging Technology Center by MDGovpics, licensed under BY 2.0 via Openverse.