Remediation guide

WCAG Compliance for AI-Generated Sites: Fix the 5 Gaps That Trigger ADA Demand Letters

Lovable, Bolt, v0, Webflow, and similar builders produce great-looking sites fast — but they routinely skip five basic accessibility attributes that serial ADA filers scan for automatically. This guide shows what those gaps are, why AI builders create them, and exactly how to close each one.

Not legal advice. ShipSafe identifies common risk patterns based on WCAG 2.1 guidelines. This guide is educational, not a legal opinion. For a compliance determination that holds up in court, consult a qualified attorney.

Why AI builders ship accessibility gaps by default

AI site builders optimize for visual output. When you prompt Lovable to "build a landing page for my SaaS," it produces markup that looks correct in a browser — because the browser renders most accessibility failures invisibly. A missing lang attribute has no visible effect. An image without alt text looks identical on screen. Insufficient color contrast is sometimes the designer's intentional aesthetic choice.

The result is a site that passes a visual review but fails when a screen reader user, a keyboard-only user, or — more practically — an automated accessibility scanner reads the actual HTML. The scanner that a serial ADA demand-letter firm runs is not looking at how the page looks. It is looking at the markup.

This is not unique to any one builder. It is the default output of a process optimized for speed and visual fidelity. Fixing it requires about an hour and five targeted changes.

The 5 fixes

These are the failures that appear most consistently in AI-generated sites and that appear most consistently in ADA demand letters targeting websites. All five map to WCAG 2.1 Level A or AA criteria — the baseline that courts apply.

  1. Add a lang attribute to your HTML tag WCAG 3.1.1 — Level A

    Screen readers use the lang attribute to select the correct pronunciation rules, accent, and voice. Without it, a user whose screen reader defaults to Spanish will hear your English text read in Spanish phonetic rules — often rendering it completely unintelligible.

    The fix is a single attribute on your opening HTML tag:

    <html lang="en">

    Use the appropriate IANA language subtag for your content language. For US English: lang="en". For French: lang="fr". For Spanish: lang="es".

    How to fix it in your builder: In Lovable and Bolt, open the code view and edit index.html directly. In Webflow, go to Site Settings → SEO → HTML lang attribute. In WordPress, the lang attribute is typically set from your site's language setting under Settings → General.

  2. Label every form input WCAG 4.1.2 — Level A

    Placeholder text (placeholder="Email address") is not a label. It disappears when a user starts typing, it is not reliably announced by screen readers, and it carries no semantic relationship to the field. An unlabeled input is one of the most commonly cited failures in ADA demand letters targeting contact forms, newsletter signups, and checkout flows.

    Option A — visible label (preferred): pair a <label> element with the input using matching for and id attributes:

    <label for="email">Email address</label>
<input id="email" type="email" placeholder="you@example.com">

    Option B — visually hidden label: if your design doesn't allow a visible label, add an aria-label attribute directly to the input. This satisfies the accessibility requirement without changing the visual layout:

    <input type="email" aria-label="Email address" placeholder="you@example.com">

    Every <input>, <select>, and <textarea> on your site needs one or the other. A button that shows only an icon (a search icon, a close X) needs aria-label too.

  3. Add alt text to images WCAG 1.1.1 — Level A

    Every <img> tag must have an alt attribute. For images that convey information, the alt text should describe what the image communicates — not just what it shows. For purely decorative images (dividers, background textures), use an empty alt="" so screen readers skip the element entirely.

    <!-- Informative image: describe what it communicates -->
<img src="dashboard.png" alt="Dashboard showing 142 active users and a 94% uptime graph">

<!-- Decorative image: empty alt tells screen readers to skip it -->
<img src="divider-wave.svg" alt="">

<!-- Wrong: meaningless to a screen reader user -->
<img src="hero.jpg" alt="image">

    AI builders sometimes generate alt="[object Object]" or alt="photo" — these are technically present but still a failure. Review every image for meaningful content. Hero images, team photos, product screenshots, and infographics all need real descriptions.

  4. Fix color contrast WCAG 1.4.3 — Level AA

    WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 between text and its background for normal-size text, and 3:1 for large text (18pt/24px regular weight, or 14pt/approximately 18.67px bold). AI builders often use light gray text on white backgrounds or low-contrast text over a branded color — a common design aesthetic that fails this criterion.

    How to check: paste your URL into ShipSafe and it will flag the most common contrast failures. You can also use Chrome DevTools: right-click any element → Inspect → click the color swatch in the Styles panel → the contrast ratio appears under Accessibility, with a pass/fail indicator.

    How to fix: darken the text color or increase the background lightness until the ratio reaches 4.5:1. WebAIM's Contrast Checker lets you adjust hex values interactively and shows the ratio in real time. Common failures: #999999 on white (2.85:1 — fails), #767676 on white (4.54:1 — passes).

  5. Add a skip-to-main-content link WCAG 2.4.1 — Level A

    Keyboard users (and screen reader users in browse mode) navigate through page elements with the Tab key. Without a skip link, a user must Tab through every navigation item, logo link, and header element before reaching the main content — on every page load, every time. A skip link lets them jump directly to the content in one keypress.

    Add this as the first element inside <body>:

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

<!-- The target, on your main content wrapper -->
<main id="main">
  ...
</main>

    The skip link should be visually hidden by default but visible on keyboard focus (so sighted keyboard users can see and use it). Add this CSS:

    .skip-link {
  position: absolute;
  left: -9999px;
  top: 8px;
  background: #14181f;
  color: #fff;
  padding: 10px 16px;
  border-radius: 8px;
  font-weight: 600;
  z-index: 9999;
}
.skip-link:focus {
  left: 12px;
}
Also worth checking: your privacy policy. ADA demand letters targeting California businesses frequently bundle a California Consumer Privacy Act (CCPA) claim alongside the accessibility allegations. A missing privacy policy is a separate legal exposure, but it appears in the same filing. ComplyKit generates a free privacy policy in your browser — no signup, no lawyer fees for the basic version.

Check your site with ShipSafe

ShipSafe reads your page's HTML and flags the most common accessibility and privacy failures that appear in ADA demand letters: missing lang, unlabeled inputs, images without alt, contrast failures, missing skip navigation, no privacy policy link, and more. You get a plain-English risk report — not an audit code dump — in under 10 seconds.

Paste your URL after making these fixes to confirm the findings are resolved. ShipSafe also shows what a serial filer's scanner would still find, so you know exactly where you stand before someone else looks.

Check my site with ShipSafe →

Frequently asked questions

Is my AI-generated site (Lovable, Bolt, v0) really at risk of an ADA demand letter?

Yes — for a specific reason. Serial ADA filers use automated scanners that look for a short list of easily detectable failures: no lang attribute, unlabeled form fields, images without alt text, and insufficient color contrast. AI builders produce these failures consistently, which makes the sites easy to identify at scale. A site doesn't need to be large or commercial to be targeted — filings have covered small business landing pages, portfolios, and early-stage SaaS products.

What WCAG level do I need to meet — A, AA, or AAA?

WCAG 2.1 Level AA is the standard applied in ADA litigation and the one referenced in most legal settlements and government guidance. Level A is the floor — the most basic requirements (all five fixes in this guide are Level A or AA). Level AAA has requirements that are impractical to meet universally and is not expected for general web content. Targeting Level AA is the right goal for a typical business website.

Can I get a demand letter for a small business site or side project?

Yes. ADA Title III applies to places of public accommodation, which courts in several circuits have held includes websites open to the public. Serial filers specifically target small and mid-size businesses because they're less likely to have legal resources to contest. A 2024 study found the vast majority of ADA website lawsuits targeted businesses with fewer than 50 employees. Size and site age are not defenses.

What's the difference between ADA and WCAG?

The ADA (Americans with Disabilities Act) is a US civil rights law. WCAG (Web Content Accessibility Guidelines) is a technical standard published by the W3C. Courts use WCAG as the practical benchmark for whether a website meets the ADA's accessibility requirement — but WCAG is not a law itself. Complying with WCAG 2.1 AA substantially reduces ADA litigation risk, but a passing audit score is not a legal guarantee of compliance.

Does fixing accessibility also help my SEO?

Significantly, yes. The lang attribute, descriptive alt text, labeled form fields, and semantic heading structure all improve how search engine crawlers parse and index your pages. Google's crawlers are essentially sophisticated screen readers — anything that helps a screen reader navigate your page helps a crawler too. Image alt text in particular is a direct SEO signal; it's how crawlers understand image content and index it in Google Image Search.

How do I get documentation proving my site is accessible?

A Voluntary Product Accessibility Template (VPAT) is the formal document used in enterprise procurement and legal contexts, but it's overkill for most small businesses. The practical first step is running a documented scan (ShipSafe flags the automatically-detectable issues), fixing the findings, and recording when you checked and what you changed. That audit trail — timestamped screenshots of your scan results before and after — matters far more in a small-business ADA dispute than a formal VPAT.

Also in the Copper Bay Labs ship-safety suite

Accessibility and privacy risk are two of several gaps to close before you ship. These free tools cover the rest:

Privacy policy ComplyKit

Generate a privacy policy, terms of service, and cookie notice for your site — free, in your browser, no account.

 Secret scanning LeakCheck

Paste code or a config file and see exposed API keys and secrets flagged before they reach the repo.

 Security headers HardenCheck

Scan your live site's HTTP headers for missing CSP, HSTS, and other security hardening flags.

 Post-deploy ExposureCheck

Scan your live URL for exposed .env files, .git directories, source maps, and bundled secrets.