Claude Shipped a Landing Page That Sues You: An Accessibility Audit Pass You Run Before Launch

There's a particular kind of silence that comes after a lawsuit letter arrives. Not the dramatic kind — the mundane kind, where a demand letter references your "lightlyusedwidgets-bye-now.com" landing page and you realize the entire site was three files Claude wrote in ninety seconds, and no human being ever read a line of it. The form had no labels. The images had no alt text. The contrast was a fashionable pale gray on off-white that roughly one in twelve men literally cannot read.

None of this means the code is bad, exactly. It means the code was written by a system optimized for looking finished, and accessibility failures are invisible when the page looks finished. Your competitors writing about AI-built sites will cover speed scores and SEO checklists until they're blue in the face. Almost nobody covers the part where an unreviewed, AI-generated page is a standing legal exposure — and the fix is not hiring an auditor for a page that cost you $0 to build. The fix is a prompt sequence you run before deploy.

Why AI-generated pages fail accessibility in predictable ways

LLMs don't ship random accessibility bugs. They ship the same accessibility bugs, over and over, because of how they generate code. Claude is predicting what a finished-looking landing page looks like, and finished-looking is not the same as compliant. The recurring offenders:

• Images with no alt attributes, or alt text that's a filename. Decorative images without alt="" get announced by screen readers as "image, image, image."
• Form fields without associated labels. Claude loves a <div> styled to look like a label sitting near an <input>. A screen reader sees a text box and nothing else. This is the single most common failure on generated pages, and it's the one that kills your lead flow for users relying on assistive tech — the exact users the page exists to capture.
• Placeholder-as-label. placeholder="Email address" disappears the moment someone types, and it's explicitly not a substitute for a label under WCAG.
• Contrast that fails WCAG AA (4.5:1 for normal text). AI models trained on modern web design trends reproduce those trends, and light-gray-on-white is very much a trend.
• Missing lang attribute, missing skip links, no focus states. Tailwind's default resets remove focus outlines, and AI-generated Tailwind rarely adds them back. Keyboard users tab through your page and lose their place entirely.
• Buttons that are <div onclick>. Not keyboard reachable, not announced as interactive, invisible to the tab key.

The reason these matter legally rather than just ethically: in the United States, ADA-related web accessibility claims are typically brought under ADA Title III as applied to websites, most commonly testing against WCAG 2.1 AA as the benchmark. The exact legal threshold varies by circuit and by year, and I'm not a lawyer — but the practical takeaway doesn't require one: WCAG 2.1 AA is the target every auditor, plaintiff's firm, and settlement agreement uses. If your page meets it, your exposure drops dramatically. If your page has zero conformance because no human touched it, you're the low-hanging fruit.

And here's the part specific to AI-built pages: a normal team's site accumulates accessibility debt gradually. An AI-built page can launch on day one at 0% conformance, get traffic the same day from a paid campaign, and be indexed and scrapeable by plaintiff-firm tooling within the week. The exposure window opens immediately, not over months.

The 10-minute audit pass (before the prompts)

Before you ask Claude to fix anything, you need to know what's broken. This pass requires no expertise and about ten minutes:

1. Run automated scanning first. WAVE (the WebAIM browser extension) and axe DevTools both flag the mechanical failures — missing labels, empty buttons, missing form associations. Lighthouse's accessibility audit in Chrome DevTools does the same. These tools catch roughly a third of WCAG issues, but the third they catch is exactly the third AI-generated code fails.
2. Tab through the page. Unplug the mouse. Can you reach every interactive element? Is anything visible when focused? Can you actually submit the form and see a confirmation?
3. Check the form specifically. Every input needs a real <label for> association. This is your conversion path — if it's broken for assistive tech, it's broken for your most motivated visitors.
4. Contrast-check your text. WebAIM's contrast checker against your actual hex values. Anything under 4.5:1 for body text fails AA.

Automated tools can't judge whether alt text is meaningful or whether focus order makes sense — that's where the prompts below come in, because Claude can self-review its own output far better than it generates it cold.

The fix-it prompt sequence

Don't ask "make this accessible" — that produces a vague refactor. Run these in order, pasting the current file each time:

Prompt 1 — the audit:

Audit this HTML against WCAG 2.1 Level AA. List every violation with the specific criterion number, the offending line, and why it fails. Do not fix anything yet.

The audit-first structure matters. When you let Claude fix and audit simultaneously, it fixes optimistically and audits generously. Separating the steps forces it to enumerate real violations against the standard.

Prompt 2 — the fixes, one category at a time:

Fix the violations related to forms and labels only. Every input gets a programmatically associated <label>. No placeholders as labels. Show the diff.

Then repeat for images and alt text, then for contrast (require it to state the resulting contrast ratios — it can compute these), then for keyboard and focus. One category per pass keeps it from silently regressing a fix while making another.

Prompt 3 — the adversarial pass:

You are a screen reader user encountering this page for the first time, navigating only by keyboard. Walk through the page in order and describe what you'd hear and where you'd get stuck.

This is the single highest-value prompt in the sequence. It converts Claude from code generator into simulation, and it reliably surfaces the issues automated scanners miss — illogical focus order, an unclear form error state, a modal that traps keyboard focus.

Prompt 4 — the regression check:

Re-audit the updated file against WCAG 2.1 AA as in the first prompt. Confirm each original violation is resolved and list anything the fixes introduced.

What this doesn't replace

Be honest about the limits. Automated scanning plus AI self-review catches the mechanical majority, but a small minority of WCAG conformance — meaningful alt text quality, cognitive load, screen-reader behavior across real devices — genuinely requires human or assistive-tech testing. If this landing page is part of a large, regulated, or high-traffic property, a professional audit is still the right spend. For a campaign page built in an afternoon, the sequence above moves you from "nobody ever looked at this" to "the known, mechanical failures are fixed and documented" — which is a different legal and moral posture entirely.

One more structural point: this pass belongs inside your pre-launch routine, not beside it. The general deploy checklist covers the mechanical launch failures — tracking, meta tags, mobile behavior — in Before You Deploy: The 12-Point Checklist for Code ChatGPT or Claude Handed You, and accessibility is the item that checklist can't compress into a checkbox, because it's not a toggle, it's a process. Add it as step thirteen, run the four prompts, save the audit output alongside your files. If anyone ever asks, you have a paper trail showing the page was reviewed and remediated before launch. That alone changes the conversation.

Claude will build your landing page in ninety seconds. Spend twenty minutes more making sure it doesn't cost you ninety days.