Accessibility pass to WCAG 2.2 AA

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Accessibility pass to WCAG 2.2 AA

Launch visitors to the production site include people who use keyboards, screen readers, zoom and high-contrast settings. Accessibility problems also tend to be the same ones that confuse everyone else. Review the main pages and flows against WCAG 2.2 AA and fix what blocks people, starting with sign-up.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Change the visual design beyond what accessibility needs without showing me first.
- Add an accessibility overlay widget.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Pick the flows and check them

Cover the landing page, pricing, sign-up, login and the first screen of the product. For each, check: every action works with the keyboard alone in a sensible order; focus is always visible; nothing traps focus except open dialogs, which return focus when closed.

### 2. Names and structure

Every input has a visible label tied to it; every button and link has an accessible name (icon buttons get `aria-label`); images have meaningful `alt` text or `alt=""` when decorative; each page has one `h1` and headings in order; landmarks (`header`, `nav`, `main`, `footer`) are present.

### 3. Visual

Text contrast at least 4.5:1 (3:1 for large text and UI components), nothing conveyed by color alone, content usable at 200% zoom and 320px wide, click targets at least 24 by 24 pixels, and motion reduced when `prefers-reduced-motion` is set.

### 4. Forms and feedback

Errors are announced and tied to their fields, required fields are marked in text, and status messages (saved, sent, failed) use a live region so screen readers hear them. Fix at the shared component level so every page benefits.

## Done means

- [ ] Every main flow works by keyboard with visible focus and no focus traps.
- [ ] Inputs, buttons, links and images have accessible names; pages have one h1 and ordered headings.
- [ ] Contrast meets 4.5:1, targets are at least 24px, and pages work at 200% zoom.
- [ ] Form errors and status messages are announced to screen readers.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.