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.

Confirm each tester has working pairings — NVDA + Firefox on Windows, JAWS + Chrome on Windows, VoiceOver + Safari on macOS/iOS, TalkBack + Chrome on Android. Test the same flow across at least two screen reader/browser combinations; behavior diverges, especially around ARIA live regions.

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 1.4.3: 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold). SC 1.4.11: 3:1 for UI components and graphical objects — focus rings, form borders, icon buttons. Disabled states are exempt; placeholder text is not. Use the axe DevTools color contrast analyzer or Stark.

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 2.3.1: nothing flashes more than 3 times per second. SC 2.2.2: any auto-updating content over 5 seconds needs pause/stop/hide. Honor prefers-reduced-motion in CSS — test by toggling the OS-level setting and confirming animations actually disable, not just slow down.

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 3.3.1: errors identified in text, not by color alone. SC 3.3.3: suggestions provided when known. SC 3.3.4: legal/financial/data submissions are reversible, checked, or confirmed. Inline validation should announce via aria-live or aria-invalid; silent red borders fail screen reader users.

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.

Use the Accessibility panel in Chrome or Firefox DevTools to walk the tree and confirm each interactive element has an accessible name, correct role, and the expected state (expanded, checked, selected). The visual UI may look fine while the a11y tree exposes nothing useful — this is the ground truth.

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.

Produce the audit report (or VPAT 2.4 if required by the requesting stakeholder) summarizing scope, methodology, findings, and conformance status per success criterion. "Pass with remediation" is the right call when non-blocker issues remain on a tracked backlog with owners and dates.