WCAG 2.2 AA in an afternoon

Accessibility intimidates founders. The standard is huge (WCAG 2.2 has 87 success criteria), the tools are confusing, and the consequences of skipping it run from "nobody can use your site" to "you got sued by a serial-plaintiff law firm."

Here's the calming truth: for an MVP, you can hit WCAG 2.2 AA in about four hours. Most of the criteria don't apply to a typical web app. The ones that do are addressed by following standard semantic HTML practices, plus a few specific checks.

This is the actual checklist.

Why bother

Two reasons that should land:

One. Roughly 1 in 5 people in the US has a disability that affects how they use software. If your MVP is unusable to one in five visitors, you've capped your addressable market by 20% before you've shipped.

Two. ADA Title III lawsuits against websites are a real industry. Serial-plaintiff law firms (you can look up the names; I won't promote them) file thousands of these per year. Settlements typically run $5,000–$25,000. You don't have to be a major brand. Any commercial website with apparent revenue (ads, products, paid features) is a target. Compliance is the cheapest insurance.

The four-hour checklist

Hour 1 — Semantic HTML pass

Walk every route. Open the dev tools accessibility tab. Confirm:

• Exactly one <h1> per page, named meaningfully.
• Heading levels never skip. Don't jump from <h2> to <h4>. The screen reader builds an outline from these.
• Buttons that look like links use <button>. Links that navigate use <a>. Never the reverse.
• Form inputs have associated <label> elements (or aria-label if a visible label isn't appropriate).
• Lists are <ul> / <ol> with <li> children, not divs.
• Page regions wrapped in <main>, <nav>, <header>, <footer>, <aside> as appropriate.

In modern frameworks (React, Vue, Svelte) most of these are easy. The places they slip are:

• Custom dropdowns that should be <select> or proper combobox patterns.
• "Buttons" that are <div onClick> instead of <button>.
• Decorative icons missing aria-hidden="true" and meaningful icons missing aria-label.

Hour 2 — Keyboard pass

Unplug your mouse. Tab through every interactive element on the MVP slice.

• Every focusable element shows a visible focus ring. Tailwind: focus-visible:ring-2 focus-visible:ring-primary is plenty.
• No keyboard traps. If you open a modal, the user must be able to Escape it.
• Modal dialogs return focus to the triggering element on close.
• Custom interactive elements (anything that isn't a native button/link/input) implement appropriate ARIA roles plus keyboard handlers — or, better, are rebuilt with native elements.

The most common bug: a <div> styled to look like a button. It can't be focused with Tab. Replace with <button>.

Hour 3 — Contrast and color

Open Chrome DevTools → Lighthouse → run the Accessibility audit on every key route. Or use the Issues panel — it surfaces contrast violations in real time.

• Body text: 4.5:1 contrast ratio against background.
• Large text (18pt+ or 14pt+ bold): 3:1.
• Don't rely on color alone to convey meaning. Red borders for errors must also have a text label saying "Error: ...". Green checkmarks must also have a label saying "Success."

If your design uses muted gray text on white, run it through the contrast checker. The default text-gray-400 on white in Tailwind fails AA. Bump to text-gray-600 or darker.

Hour 4 — Final pass

• Page <title> is meaningful and unique per route. Not "App." Not "Home." Use Route name — Site name format.
• Images have alt text. Decorative images: alt="" (empty, not missing). Meaningful images: descriptive alt.
• Icon-only buttons have aria-label.
• Live regions (toasts, async results) use aria-live="polite".
• Animations respect prefers-reduced-motion. Wrap non-essential animations in a media query check.

What the audit tools catch (and miss)

Run Lighthouse → Accessibility audit. The score must be at least 95 on the home page. Sub-skill 11 in the Vibe Coder's Guide enforces this.

Lighthouse catches:

• Color contrast
• Missing form labels
• Missing alt text
• Heading order issues
• Empty buttons / links
• Page title presence

Lighthouse misses (you must check by hand):

• Whether your custom dropdowns work with keyboard
• Whether focus order makes sense
• Whether modal dialogs trap focus correctly
• Whether the language of the content is correctly indicated
• Whether dynamic content updates are announced

What WCAG 2.2 added beyond 2.1

For 2.2 specifically, two new criteria matter for typical MVPs:

• 2.4.11 Focus Not Obscured (Minimum): when an element has focus, it must not be entirely hidden by other content (sticky headers, cookie banners). If you have a sticky header, make sure focused inputs scroll into view above it.
• 2.5.7 Dragging Movements: any drag-to-reorder UI must have a non-drag alternative (e.g., up/down buttons). If your MVP doesn't have drag UI, this doesn't apply.

The other 2.2 additions (target size, focus appearance, consistent help) are easy to satisfy with sensible defaults — buttons at least 24×24 CSS pixels, focus rings already present, contact link in the footer.

What "passing" looks like

When you're done:

• Lighthouse Accessibility score: 95+ on every key route.
• Manual keyboard pass: you can Tab through the MVP slice with no traps and no surprises.
• Manual contrast spot check: no element fails AA.
• VoiceOver or NVDA spot check: page reads logically when you turn off your monitor.

That's it. Four hours, MVP-grade WCAG 2.2 AA. The skills' accessibility checklist (sub-skill 09) is exactly this in step-by-step form for an agent to run.

Disability rights are real, the lawsuit risk is real, and the cost of compliance is one afternoon. Just do it.

← All posts