Accessibility Testing Checklist

A step-by-step workflow for testing web accessibility. Work through each group in order: start with automated tools (axe, Lighthouse, Pa11y), test with a keyboard, verify with a screen reader, check visual and responsive behavior, then audit cognitive and content patterns.

Interactive QA

0 of 46 items complete

Automated Scanning

Run axe-core or Lighthouse accessibility audit Check for zero critical and serious violations. Use the axe browser extension or Chrome DevTools Lighthouse panel.
Run Pa11y from the command line Pa11y is a CLI-friendly automated tester — useful for batch-checking many URLs and integrating into shell scripts. Combine with axe for broader rule coverage.
Test with WAVE for visual feedback The WAVE browser extension overlays icons on the page showing accessibility errors, alerts, and structural elements — useful for visualizing landmark and heading structure at a glance.
Validate HTML with W3C validator Check for missing alt attributes, duplicate IDs, and nesting errors. Use the W3C Markup Validation Service.
Check color contrast with browser DevTools Inspect text, borders, and focus indicators for sufficient contrast ratios. See the Color Contrast guide for requirements.
Verify heading hierarchy with a headings outline tool Headings h1 through h6 should follow a logical order with no skipped levels. See the Semantic HTML guide for proper document structure.
Confirm <html lang>, page title, and no duplicate IDs These are easy automated catches: every page needs a lang attribute on <html>, a unique <title>, and no repeated id values. axe and Lighthouse both flag these.
Wire automated checks into CI on every pull request Run axe-core or Pa11y as a CI step so accessibility regressions fail builds before they reach production. See the automated testing guide for setup.

Visual and Responsive

Page is usable at 200% browser zoom No content clipping and no horizontal scrolling for main content at double the default zoom level.
Touch targets are at least 24x24 CSS pixels Test buttons, links, and form controls on mobile devices or using responsive mode in DevTools.
Content reflows at 320px viewport width Layout should adapt to a single column with no horizontal scrolling (WCAG SC 1.4.10 Reflow).
Dark mode maintains contrast ratios Test all text, borders, and interactive elements in both light and dark themes for sufficient contrast.
Animations respect prefers-reduced-motion Only essential motion should play when the user has enabled the reduced motion preference.
Text-spacing override doesn't break layout Apply the WCAG 1.4.12 text-spacing override (line-height 1.5×, paragraph spacing 2×, letter spacing 0.12em, word spacing 0.16em) via a bookmarklet. Content must remain readable with no text clipped or overlapping.
Content visible and operable with CSS disabled Toggle CSS off in DevTools — the page should still be readable in source order, with all interactive controls reachable. This surfaces hidden tabindex problems and confirms semantic structure.
Windows High Contrast / forced-colors mode preserves UI Test in Windows High Contrast Mode (or Chrome's Rendering panel forced-colors: active simulation). Icons, focus indicators, and form controls must remain visible — avoid background images for critical UI, use currentColor for icons.
Images of text are avoided where real text would work Text rendered as an image can't be resized, translated, or read by screen readers reliably. Use real text styled with CSS unless the image is a logo or essential brand asset (WCAG 1.4.5 Images of Text, Level AA).

Cognitive and Content

Form fields have visible labels (not just placeholder text) Placeholders disappear when typing and often have insufficient contrast. Every field needs a persistent visible <label>. See the Forms pattern.
Error messages are clear, specific, and constructive "Invalid input" is not enough — say what's wrong and how to fix it ("Email must include an @ symbol"). Errors must be programmatically associated with their fields via aria-describedby.
DOM order matches visual order Use a screen reader or Tab key to confirm content reads in the visual order it appears. CSS order or flex-direction: row-reverse can desynchronize reading from layout (WCAG 1.3.2 Meaningful Sequence).
Color is not the only way to convey meaning Required fields, error states, links in body text, status indicators — each must be distinguishable by something beyond color (icon, label, underline, pattern). WCAG 1.4.1 Use of Color, Level A.
Time limits can be extended, paused, or disabled If your app has any session or interaction time limit, users must be able to extend it (at least 10× the original) or disable it (WCAG 2.2.1 Timing Adjustable, Level A). Exempts real-time auctions and similar essential timers.
Plain language used; avoid unexplained jargon Read each page out loud — if a sentence is hard to parse for a non-specialist, simplify. Aim for a 9th-grade reading level for general content. Define acronyms on first use.

Frequently asked questions

What's the difference between manual and automated accessibility testing?

Automated testing (axe, Lighthouse, Pa11y, WAVE) runs in seconds and catches roughly 30% of WCAG violations — missing alt text, low contrast, broken ARIA references, duplicate IDs, missing labels. Manual testing (keyboard navigation, screen reader walk-through, zoom and reflow checks, cognitive review) catches the other 70% — focus order, meaningful announcements, readable structure, content sequence, dragging alternatives, and time limits. You need both. Automated tests gate every PR; manual tests gate every release.

What's the difference between this and the developer checklist?

The Developer checklist is for items you can verify by reading or running code — markup, semantics, ARIA, color contrast, focus management. This Testing checklist is the QA-facing version — what to actually run, click, and listen for. They're complementary: developers self-check with the dev checklist, QA verifies with this one.

Can I use Pa11y for accessibility testing?

Yes — Pa11y is a solid command-line accessibility tester, built on the same HTML_CodeSniffer + axe rule sets that power browser extensions. It's particularly useful for batch-testing many URLs (e.g., crawling a sitemap) and for shell-script integration. For day-to-day work most teams pair Pa11y (CLI/CI) with axe DevTools (in-browser debugging) — they overlap heavily but the workflows complement each other. See the automated testing guide for setup.

How do I integrate accessibility testing into CI/CD?

Run axe-core or Pa11y as a GitHub Action / GitLab CI job on every pull request, failing the build on new violations. For component-level catches, add jest-axe (or @axe-core/playwright) to your unit and end-to-end test suites. The goal is to make accessibility regressions visible at PR time, not at release time. See the automated testing guide for tool-by-tool setup instructions.

What tools do I need for the manual portions?

A keyboard (for keyboard testing), at least one screen reader (NVDA + Firefox on Windows, VoiceOver + Safari on Mac, or JAWS + Chrome), and one automated tool like axe DevTools, Lighthouse, or Pa11y. Browser DevTools' built-in accessibility tree inspector handles most of the ARIA-debugging work.

How long does a full test run take?

Plan ~30-60 minutes per primary user flow for a thorough manual pass — keyboard, screen reader, zoom, and reduced-motion testing. Automated tools run in seconds but only catch ~30% of real issues. Most teams run automated checks per-PR and manual flows per-release.

Which screen reader should I prioritize?

If you only have time for one combination: NVDA + Firefox on Windows covers the largest accessibility user base. Add VoiceOver + Safari on iOS for mobile coverage. JAWS is the most expensive but still widely used in corporate environments — test it if your audience skews enterprise. See the Screen Reader Testing guide for setup.

Do automated tools replace manual testing?

No. Automated tools catch about 30% of WCAG violations — things like missing alt text, low contrast, broken ARIA references. They can't tell you whether a keyboard trap exists, whether focus moves logically, or whether a screen reader announces the right thing. Manual testing covers the remaining 70%.

When do I need to retest after fixing an issue?

Always retest the specific issue with the same tool/method that found it (closing the loop). For high-impact fixes (focus management, keyboard handlers, dynamic content), re-run a full flow test — not just the spot fix — because fixes can introduce regressions elsewhere.

What about color contrast on hover and focus states?

Test every state: default, hover, focus, active, disabled. Each must independently meet WCAG contrast minimums (4.5:1 normal text, 3:1 large text and UI components). The Color Contrast guide covers tooling and edge cases.

How do I test responsive breakpoints?

Test at 320px (smallest mobile), 768px (tablet), 1024px (desktop), and 200% browser zoom on each. Content must reflow, not horizontally scroll. Focus indicators must remain visible. Touch targets must meet 24×24px minimum on mobile. See the Mobile checklist for mobile-specific tests.

Accessibility Testing Checklist

Automated Scanning

Keyboard Testing

Screen Reader Testing

Visual and Responsive

Cognitive and Content

Frequently asked questions