Accessibility Compliance Checklist

List the URLs, components, and end-to-end user flows under test (sign-up, checkout, settings, key task flows). Auditing every page is rarely feasible — pick representative templates plus the highest-traffic flows. Note any auth states or feature flags reviewers need access to.

WCAG 2.2 Level AA is the standard target for most public-sector contracts, the EU Accessibility Act (effective 2025), and Section 508 refresh. Choose AAA only if a specific contract or policy demands it — most products do not pursue AAA system-wide.

Pull AAA-only criteria into the test plan — sign language for prerecorded audio (1.2.6), enhanced contrast 7:1 (1.4.6), no images of text (1.4.9), context-sensitive help (3.3.5). Confirm with the requesting stakeholder which AAA criteria are in scope; partial AAA is normal and should be documented.

Set up axe DevTools, Lighthouse, WAVE, or Pa11y CI against the target URLs. Automated tools catch roughly 30-40% of WCAG issues — they are a baseline, not the audit. Save a baseline scan now so you can diff against it after remediation.

SC 1.1.1: every img needs an alt attribute — descriptive for content images, empty (alt="") for decorative. Check icon-only buttons for aria-label, SVGs for title or aria-labelledby, and CAPTCHA for an accessible alternative. Background images conveying meaning are a frequent miss.

SC 1.2.2 requires captions for prerecorded video; SC 1.2.5 requires audio description at AA. Auto-generated YouTube captions do not meet 1.2.2 — they need human review. For live audio (1.2.4, AA), confirm a real-time captioning workflow exists.

SC 1.4.10: content must reflow without two-dimensional scrolling at 320 CSS px width. SC 1.4.4: text must scale to 200% without loss of content. Common failures — fixed-width modals, sticky headers eating viewport, horizontal data tables that should remain scrollable.

SC 2.1.1: all functionality available via keyboard. Tab order should match visual order; verify no keyboard traps (SC 2.1.2) in modals, date pickers, or embedded iframes. Custom components like dropdowns, tabs, and tree views need ARIA Authoring Practices keyboard patterns — arrow keys, Home/End, Escape.

SC 2.4.7 requires a visible focus indicator; SC 2.4.11 (new in WCAG 2.2) sets minimum size and contrast for it (3:1 against adjacent colors, at least 2 CSS px perimeter). The most common failure is a global outline:none reset that was never replaced — grep your CSS for it.

SC 2.2.1: users must be able to turn off, adjust, or extend any time limit (or warn 20+ seconds before timeout with a one-key extension). Verify session timeout dialogs are reachable by keyboard and announced by screen readers — silent logout is a hard fail.

SC 3.1.1 requires lang on the html element; SC 3.1.2 requires lang on any inline span whose language differs. Screen readers switch pronunciation engines based on this — wrong or missing lang produces gibberish. Localized sites with templated layouts often emit lang="en" on every page regardless of locale.

SC 3.3.2 + SC 1.3.1: every input needs a visible label associated via for/id, aria-labelledby, or wrapping label. Placeholder text alone is not a label — it disappears on focus and fails contrast. Verify required fields announce required state via aria-required or the required attribute.

SC 4.1.2: name, role, value programmatically determined. Run axe-core via DevTools or Playwright/Cypress integration. Watch for div soup with role="button" instead of native button, conflicting ARIA (aria-hidden on a focusable element), and broken aria-labelledby references.

SC 4.1.3: status messages (toasts, form-save confirmations, search-result counts) must be announced without moving focus. Verify aria-live="polite" or role="status" on the container, and that the container exists in the DOM before the message is injected — late-mounted live regions do not announce.

Run axe-core, Lighthouse, and Pa11y across all in-scope URLs. Export the reports and attach them to this step — they become evidence for SOC 2 / VPAT documentation. Diff against the baseline scan from setup to confirm new violations did not appear during testing.

Each ticket should cite the failing SC (e.g., "1.4.3 Contrast (Minimum)"), the page/component, reproduction steps, the assistive tech used, and severity (blocker / critical / major / minor). Blocker = a Level A or AA failure that prevents task completion for a user with disabilities.

Blockers must close before the audit can sign off as conformant. Coordinate with engineering to triage into the current sprint, retest each fix against the original failing flow and assistive tech pairing, and update the ticket with the verified fix sha.