Pre-launch Accessibility Checklist

The final accessibility check before shipping a new feature, page, or app. 30 items covering the must-fix-before-launch issues — keyboard, screen readers, forms, color, errors, and pre-launch edge cases. Pair it with the role-specific checklists for deeper coverage.

Interactive Pre-launch

0 of 30 items complete

Keyboard & Focus

Every interactive element is reachable with Tab in a logical order Tab through every page from top to bottom. The order should match the visual reading order. No element should be skipped or out of sequence. (SC 2.1.1, 2.4.3) Keyboard Testing guide
Every focused element has a visible focus indicator with at least 3:1 contrast Never outline: 0 without a replacement. The focus ring must be visible against any background it can land on. (SC 2.4.7, 2.4.11)
Modal dialogs trap focus while open and return focus to the trigger on close Tab inside the modal cycles within it; closing the modal returns focus to the element that opened it. The native <dialog> element handles this for free. Modal pattern
Escape closes modals, dropdowns, popovers, and tooltips Any transient, dismissible UI must respond to Escape. Test every overlay component on the page. (SC 1.4.13)
No keyboard traps — Tab can always exit any component Tab and Shift+Tab should always move focus elsewhere on the page (or to the next page section). Watch out for embedded iframes, custom widgets, and date pickers. (SC 2.1.2)

Screen Reader & Semantics

Every page has exactly one <h1> and it describes the page The H1 is the page's primary subject. Don't reuse the site name. Avoid generic words like "Welcome." (SC 2.4.6) Headings & Landmarks guide
Heading levels don't skip H2 → H3, never H2 → H4. Use a browser extension like HeadingsMap or axe DevTools to view the outline. (SC 1.3.1)
Major regions use the right landmarks <header>, <nav>, <main>, <footer>. Exactly one <main> per page. Multiple <nav> elements need unique aria-labels. (SC 1.3.1, 2.4.1)
Every interactive element has an accessible name Buttons, links, and form fields have visible labels or aria-label/aria-labelledby. Icon-only buttons need an explicit name. (SC 4.1.2, 2.5.3) Form Labeling guide
Tested with at least one screen reader on a real user flow NVDA + Firefox on Windows, or VoiceOver + Safari on macOS/iOS. Walk through the primary task end to end with eyes closed. Screen Reader Testing guide

Forms & Validation

Every input has an associated <label> Use <label for> or wrap the input in a label. aria-label only when there's no visible text. Placeholders are not labels. (SC 1.3.1, 3.3.2, 4.1.2) Forms pattern
Required fields are marked programmatically and visibly Use the required attribute and a visible marker like * with a key (or "(required)" appended via .visually-hidden). Don't rely on color alone. (SC 1.3.1, 1.4.1, 3.3.2)
Errors are programmatically associated with their fields aria-describedby points at the error message; the field has aria-invalid="true". Screen readers then announce the error when the field is focused. (SC 3.3.1, 3.3.3)
Form submission failure is announced and focus moves to a useful place Either move focus to the first error, or surface a summary in a role="alert" region. Don't silently fail. (SC 3.3.1, 4.1.3) Live Regions guide

Visual Design & Contrast

Body text meets 4.5:1 contrast (3:1 for large text) Large text = 18pt+ or bold 14pt+. Use a contrast checker like the one in DevTools or WebAIM's. Don't forget hover, focus, disabled, and dark-mode states. (SC 1.4.3) Color Contrast guide
UI components and meaningful graphics meet 3:1 contrast Form field borders, button outlines, focus indicators, icons that convey meaning, chart elements. The boundary that distinguishes a control from its background must be visible. (SC 1.4.11)
Text scales to 200% without loss of content or function Zoom the browser to 200%. No horizontal scroll, no clipped text, no broken layout. Use relative units (rem, em) for type. (SC 1.4.4, 1.4.10)
Color is never the only way information is conveyed Required fields, errors, statuses, and chart series need a non-color cue too: an icon, a label, a pattern, or text. Test by viewing the page in grayscale. (SC 1.4.1)

Content & Structure

Every page has a unique, descriptive <title> The title appears in the browser tab, search results, and is the first thing screen readers announce on page load. Front-load the unique part. (SC 2.4.2)
Images have appropriate alt text Informative images: describe what they convey. Decorative: alt="". Functional (icon-as-button): describe the action. Never omit the alt attribute. (SC 1.1.1) Alt Text guide
Link and button text describes the destination or action Avoid "click here," "read more," "submit." Use "Read the accessibility guide," "Save changes." Screen reader users navigate by link list. (SC 2.4.4, 2.4.9)
<html lang> is set correctly on every page Tells screen readers which pronunciation rules to use. lang="en", not omitted. Set lang on inline content in another language with a span. (SC 3.1.1, 3.1.2)

Errors, States & Feedback

Status messages use live regions Toasts, "saved successfully," cart updates, and search result counts go in a role="status" (polite) or role="alert" (urgent) live region. Don't move focus. (SC 4.1.3) Alert pattern
Loading and async states are announced "Loading…" → "12 results" — both should reach the screen reader. Use a polite live region. Spinners alone are inaudible.
Time-sensitive content can be paused, extended, or has no time limit Auto-rotating carousels need a pause control. Session timeouts need a "still here?" extend prompt at least 20 seconds before expiry. (SC 2.2.1, 2.2.2)

Edge Cases & Final Pass

prefers-reduced-motion honored — animations disabled or simplified Wrap any non-essential motion in @media (prefers-reduced-motion: no-preference). Carousels, page transitions, parallax, and decorative animations should respect the user's setting. (SC 2.3.3)
Touch targets meet at least 24×24 CSS px Buttons, links, and tap targets need a minimum hit area. 44×44 is recommended. Use padding to expand the click area without inflating visual size. (SC 2.5.8 Target Size Minimum)
Pinch-zoom is not disabled No user-scalable=no or maximum-scale=1 in the viewport meta tag. Low-vision users rely on zoom to read. (SC 1.4.4)
A skip-to-content link is the first focusable element On Tab from page load, the first stop should be a "Skip to main content" link. It can be visually hidden until focused. (SC 2.4.1) Skip Links pattern
Automated scan run — zero serious or critical issues Use axe DevTools, Lighthouse, or Pa11y on every key page. Automated tools catch ~30% of issues; resolve everything they flag, then keep going on manual checks. Automated Testing guide

Frequently asked questions

When in the release cycle should I run this?

Run it after the implementation is feature-complete but before the release is final — typically during QA gating. Items here are the must-fix-before-ship issues. Use the Developer checklist earlier (during build) and the Testing checklist when you're actively testing.

Is 30 items really enough?

It's the minimum bar — the items most likely to cause a ship-blocking accessibility complaint after launch. Each item maps to a high-severity WCAG criterion (Level A or commonly-litigated AA). Pair it with the Developer checklist for full coverage; this is the focused pre-flight version.

What if my product is a mobile app or PWA?

Many items still apply (forms, screen reader, color contrast). For mobile-specific items — touch targets, gesture alternatives, pinch-zoom — use the Mobile Accessibility checklist alongside this one.

How long does this take?

Plan ~1 hour for a focused single-page run-through. If the implementation has already been verified against the Developer checklist during build, most items will pass quickly and you're just confirming.

Can I share the checklist progress with my team?

Progress is stored in your browser's localStorage, scoped per checklist. It doesn't sync across devices or team members. For shared tracking, print the checklist (Cmd/Ctrl-P) or screenshot the progress bar — both work well for status updates.

What if I find an issue mid-checklist?

Note it, finish the rest of the checklist, then triage. Fix the must-block-launch issues; file lower-priority items as follow-ups. Re-test the specific failure mode after each fix to confirm the change worked and didn't regress elsewhere.

Does passing this guarantee WCAG 2.2 AA compliance?

No — passing this 30-item checklist confirms you've cleared the most common high-severity issues, but full WCAG 2.2 AA conformance requires all ~50 applicable success criteria. Use the WCAG 2.2 Compliance checklist for the complete legal-conformance audit.

What's the most-missed item in pre-launch?

Focus management around dynamic content. Modals that don't trap focus, route changes that don't move focus, and error messages that don't announce to screen readers are the three issues that most often slip through. The Focus Management guide covers all three.