Website Accessibility Testing Checklist: Complete QA Guide

Accessibility testing shouldn't be a mystery. When I work with QA teams, I find they want clear, actionable checklists—specific things to test, specific ways to test them, specific pass/fail criteria. This guide provides exactly that.

This checklist covers systematic accessibility testing from automated scans through manual verification to assistive technology testing. Work through it methodically for comprehensive coverage, or use relevant sections for targeted testing.

Q: What should an accessibility testing checklist include?

A: A complete accessibility testing checklist covers: automated scanning (catching 30-40% of issues), keyboard navigation testing, visual testing (focus indicators, color contrast), content review (headings, alt text, form labels), screen reader testing, and mobile accessibility. Each area needs specific test cases with clear pass/fail criteria based on WCAG requirements.

Setting Up for Testing

Tools You'll Need

Automated scanners (pick at least one):

• axe DevTools - Browser extension
• Chrome Lighthouse - Built into Chrome DevTools
• TestParty - For comprehensive scanning with fix suggestions

Screen readers (pick based on platform):

• NVDA (Windows, free) - nvaccess.org
• VoiceOver (Mac/iOS) - Built-in
• JAWS (Windows, commercial) - If available

Color contrast checkers:

• WebAIM Contrast Checker - webaim.org/resources/contrastchecker
• Browser DevTools - Built into Chrome/Firefox

Browser DevTools:

• Accessibility Inspector (built into Chrome, Firefox)

Testing Environment

• Test in primary supported browsers (Chrome, Firefox, Safari, Edge)
• Test at different viewport sizes (desktop, tablet, mobile)
• Test with default browser/OS settings first
• Have screen reader installed and ready

Automated Testing Checklist

Running Automated Scans

• [ ] Run axe or Lighthouse on every page template
• [ ] Run on multiple page states (empty forms, error states, modal open, etc.)
• [ ] Run on interactive states (dropdown open, tab selected, etc.)
• [ ] Document all issues found with severity and location
• [ ] Verify fixes don't introduce new issues

What Automated Tools Check

Automated tools catch issues like:

• Missing alt text on images
• Missing form labels
• Color contrast failures
• Invalid ARIA attributes
• Missing document language
• Duplicate IDs
• Empty buttons/links
• Missing page title

Remember: Automated tools catch approximately 30-40% of accessibility issues. Manual testing catches the rest.

Keyboard Navigation Checklist

Basic Navigation

• [ ] Tab through entire page - Can you reach all interactive elements?
• [ ] Shift+Tab backward - Does reverse navigation work?
• [ ] Focus order logical - Does Tab move in expected sequence?
• [ ] Focus visible - Can you see where focus is at all times?
• [ ] No keyboard traps - Can you Tab away from every element?
• [ ] Skip link works - Does skip link bypass navigation?

Interactive Elements

• [ ] Links activate with Enter
• [ ] Buttons activate with Enter and Space
• [ ] Checkboxes toggle with Space
• [ ] Radio buttons select with Arrow keys
• [ ] Dropdowns open and navigate with Arrow keys
• [ ] Modals trap focus - Can't Tab to background
• [ ] Modals close with Escape
• [ ] Menus close with Escape

Custom Components

• [ ] Custom buttons keyboard accessible
• [ ] Custom dropdowns work with Arrow keys
• [ ] Carousels pausable and navigable
• [ ] Tabs switchable with Arrow keys
• [ ] Accordions expandable with Enter/Space
• [ ] Date pickers fully keyboard operable
• [ ] Autocomplete navigable with keyboard

Focus Management

• [ ] Modal open - Focus moves into modal
• [ ] Modal close - Focus returns to trigger
• [ ] Dynamic content - Focus managed appropriately
• [ ] Page navigation (SPA) - Focus moves to new content
• [ ] Error states - Focus moves to error or error summary

Visual Testing Checklist

Focus Indicators

• [ ] Every focusable element has visible focus indicator
• [ ] Focus indicator has sufficient contrast (3:1 minimum)
• [ ] Focus indicator is not removed by CSS
• [ ] Focus indicator consistent across site
• [ ] Focus visible in all color themes (if applicable)

Color Contrast

• [ ] Normal text meets 4.5:1 against background
• [ ] Large text meets 3:1 (18pt+ or 14pt+ bold)
• [ ] UI components meet 3:1 (buttons, form fields)
• [ ] Focus indicators meet 3:1
• [ ] Test in all color themes (light/dark modes)

Visual Presentation

• [ ] Text resizable to 200% without loss of content/function
• [ ] Content reflows at 400% zoom or 320px width
• [ ] No horizontal scrolling at 400% zoom (with exceptions)
• [ ] Spacing adjustable without content loss
• [ ] Text images minimized - use actual text when possible

Color Independence

• [ ] Color not sole indicator of meaning
• [ ] Error states indicated by more than red color
• [ ] Required fields indicated by more than color
• [ ] Links distinguishable from surrounding text by more than color
• [ ] Charts/graphs accessible without color perception

Content Testing Checklist

Headings

• [ ] Page has one H1
• [ ] Heading hierarchy logical (no skipped levels)
• [ ] Headings describe content sections
• [ ] Headings used for structure not just styling

Images

• [ ] All images have alt attribute
• [ ] Alt text meaningful and contextual
• [ ] Decorative images have empty alt (alt="")
• [ ] Complex images have extended description
• [ ] Image links describe destination

Links

• [ ] Link text describes destination (not "click here")
• [ ] Links distinguishable from surrounding text
• [ ] Same link text goes to same destination
• [ ] New window/tab indicated if applicable

Forms

• [ ] Every field has visible label
• [ ] Labels programmatically associated with fields
• [ ] Required fields indicated
• [ ] Error messages specific and associated with fields
• [ ] Autocomplete attributes present for common fields
• [ ] Form validation accessible (errors announced)
• [ ] Field groups labeled with fieldset/legend

Tables

• [ ] Tables used for data (not layout)
• [ ] Header cells marked with <th>
• [ ] Scope attributes present on headers
• [ ] Caption describes table content
• [ ] Complex tables have header associations

Multimedia

• [ ] Videos have captions
• [ ] Audio has transcript
• [ ] Video has audio description (if needed)
• [ ] Media players keyboard accessible
• [ ] Autoplay controllable - can pause/stop

Page Structure

• [ ] Page title descriptive and unique
• [ ] Language declared (lang attribute on <html>)
• [ ] Landmarks present (header, nav, main, footer)
• [ ] Reading order logical when CSS disabled

Screen Reader Testing Checklist

Basic Comprehension

• [ ] Page title announced on load
• [ ] Headings provide page outline (test with H key navigation)
• [ ] Landmarks identified (test with landmark navigation)
• [ ] Images described appropriately
• [ ] Reading order makes sense

Interactive Elements

• [ ] Links announce destination
• [ ] Buttons announce action
• [ ] Form fields announce labels
• [ ] Error messages announced
• [ ] Success messages announced

Dynamic Content

• [ ] Route changes announced (SPAs)
• [ ] Modal dialogs announced
• [ ] Expanding content announced (accordions, dropdowns)
• [ ] Status updates announced via live regions
• [ ] Errors announced without requiring navigation

Navigation

• [ ] Can navigate by headings (H key)
• [ ] Can navigate by landmarks (D key in NVDA)
• [ ] Can navigate by links (K key)
• [ ] Can navigate by form fields (F key)
• [ ] Skip link target receives focus

Mobile Accessibility Checklist

Touch Targets

• [ ] Touch targets at least 44x44px (recommended)
• [ ] Adequate spacing between targets
• [ ] No overlapping touch areas

Gestures

• [ ] Complex gestures have alternatives (pinch, multi-finger)
• [ ] Swipe actions have button alternatives
• [ ] Shake/tilt actions have alternatives

Orientation and Zoom

• [ ] Works in portrait and landscape
• [ ] Pinch zoom not disabled
• [ ] Text size responds to system settings

Mobile Screen Reader

• [ ] VoiceOver (iOS) works correctly
• [ ] TalkBack (Android) works correctly
• [ ] All content accessible via screen reader gestures

Page-by-Page Testing Template

For Each Page Template:

1. Automated scan:

• Run axe/Lighthouse
• Document issues

2. Keyboard test:

• Tab through entirely
• Test all interactive elements
• Verify focus indicators

3. Visual test:

• Check contrast
• Verify color independence
• Test zoom/resize

4. Content test:

• Verify headings
• Check alt text
• Test forms
• Review links

5. Screen reader test:

• Navigate page
• Test interactive elements
• Verify announcements

6. Mobile test:

• Touch targets
• Screen reader
• Orientation

Issue Documentation Template

For each issue found:

Issue: [Brief description]
Page: [URL]
Element: [CSS selector or location]
WCAG Criterion: [e.g., 1.1.1 Non-text Content]
Severity: [Critical/Serious/Moderate/Minor]
Steps to reproduce: [How to find/reproduce issue]
Expected behavior: [What should happen]
Actual behavior: [What actually happens]
Suggested fix: [If known]

Prioritizing Issues

Critical (Fix immediately)

• Complete barriers to access (can't navigate, can't submit form)
• Keyboard traps
• Missing form labels preventing completion
• Critical ARIA errors

Serious (Fix soon)

• Missing alt text on informative images
• Missing form error associations
• Focus indicators invisible
• Insufficient color contrast on primary content

Moderate (Fix in normal workflow)

• Missing skip links
• Missing language declarations
• Inconsistent focus order
• Missing table headers

Minor (Fix when convenient)

• Missing autocomplete attributes
• Verbose alt text
• Minor contrast issues on non-essential elements
• Redundant ARIA

FAQ Section

Q: How often should we run accessibility testing?

A: Automated scans should run with every build (CI/CD integration). Manual testing should happen before releases, when adding new features, and periodically (quarterly) for regression. Screen reader testing for new components and user flows.

Q: Should every team member know how to test accessibility?

A: Developers should know basic keyboard and automated testing. QA should have deeper manual and screen reader testing skills. Having at least one accessibility specialist on the team—or access to one—helps for complex issues.

Q: How do we handle third-party components that aren't accessible?

A: Document the issues, report to vendor, and consider alternatives. If the component is essential, explore workarounds or custom implementations. Track third-party accessibility issues separately.

Q: What percentage of issues do automated tools actually catch?

A: Research suggests automated tools catch 30-40% of accessibility issues. They're excellent for catching code-level problems (missing attributes, invalid ARIA) but can't evaluate user experience, meaningful content, or complex interactions.

Q: How do we prioritize accessibility testing with limited time?

A: Focus on: critical user paths (checkout, signup, core features), pages with highest traffic, recently changed components. Automated testing provides baseline; prioritize manual testing on the most important flows.

Integrating Accessibility Testing

Make accessibility testing sustainable:

• Automated scans in CI/CD - Catch issues early
• Testing checklist in QA process - Systematic verification
• Accessibility in definition of done - Team accountability
• Regular training - Keep skills current
• Track metrics - Monitor improvement over time

Accessibility testing is most effective when it's integrated into existing workflows, not added as an afterthought.

Need help identifying accessibility issues efficiently? Get a free accessibility scan to establish your baseline and prioritize testing efforts.

Related Articles:

• How Do I Test My Website for Accessibility for Free?
• How Do I Test with a Screen Reader?
• WCAG 2.2: What's New and How to Comply

At TestParty, we're all about making accessibility achievable for everyone. AI helped us create this content so we can share more knowledge with the community. Our human team reviewed everything, but accessibility compliance varies widely—please consult with experts who understand your specific needs.