Skip to main content

Accessibility Checklist

This checklist maps WCAG 2.1 Level AA requirements to practical testing steps. Use it during design reviews, development handoffs, or audits. Each section covers one of WCAG's four principles - Perceivable, Operable, Understandable, and Robust - with checklist items and a method for testing each.

Last updated: January 2026

Before you start​

Accessibility is not a feature bolt-on. Issues found late cost significantly more to fix than issues caught in design or early development. Run through this checklist iteratively as you build, not just at the end.

For people with permanent disabilities, situational limitations (bright sunlight, one hand occupied), or temporary impairments, accessible design often makes the difference between a usable product and an unusable one. Legal obligations aside, that's reason enough.

For comprehensive WCAG documentation, see the W3C Web Accessibility Initiative (WAI) resources.

Perceivable​

Users must be able to perceive the information presented.

Text alternatives​

How to test: Use a screen reader to navigate key pages. Can you understand the content without seeing the images?

Time-based media​

How to test: Watch videos with sound off. Can you follow the content using captions alone?

Adaptable content​

How to test: Disable CSS and check if content order and structure still make sense.

Distinguishable​

How to test: Use a color contrast checker. Test at 200% zoom. Resize browser to 320px width.

Operable​

Users must be able to operate the interface.

Keyboard accessible​

How to test: Navigate the entire interface using only Tab, Shift+Tab, Enter, Space, and arrow keys. Can you access everything?

Enough time​

How to test: Identify any timed elements. Check that users have control over timing.

Seizures and physical reactions​

How to test: Review any animated content. Check if prefers-reduced-motion media query is respected.

How to test: Tab through the page. Is there a skip link? Does focus move logically?

Focus visibility

Default browser focus indicators are often hard to see. Consider enhancing focus styles with a clear, visible outline that has sufficient contrast.

Input modalities​

How to test: Test all interactions with mouse/trackpad, touch, and keyboard.

Understandable​

Users must be able to understand the information and interface.

Readable​

How to test: Check that <html lang="..."> is set correctly. Use a screen reader to verify language pronunciation.

Predictable​

How to test: Tab through forms. Does anything unexpected happen when focusing fields?

Input assistance​

How to test: Submit forms with errors. Are errors clearly communicated and linked to the relevant field?

Robust​

Content must be robust enough to work with current and future technologies.

Compatible​

How to test: Use browser developer tools to inspect elements. Check ARIA attributes are used correctly.

Testing tools and techniques​

Automated testing​

Automated tools catch obvious issues but miss many problems. Use them as a starting point:

  • Browser extensions (axe, WAVE)
  • Linters in your build process
  • CI/CD integration for automated checks

Manual testing​

Essential techniques:

  • Keyboard testing: Navigate without mouse
  • Screen reader testing: VoiceOver (Mac), NVDA (Windows), or browser extensions
  • Zoom testing: Test at 200% and 400%
  • Color contrast checking: Use tools to verify ratios

User testing​

Include people with disabilities in your usability testing when possible. Automated and expert testing catches issues, but nothing replaces observing actual assistive technology users.

Common accessibility mistakes​

Missing form labels: Using placeholder text instead of visible labels.

Low contrast: Light gray text on white backgrounds.

Missing alt text: Images with no alternatives, or unhelpful alt text like "image" or the filename.

Inaccessible custom controls: Custom dropdowns, modals, and widgets that don't work with keyboards.

Missing skip links: Forcing keyboard users to tab through lengthy navigation repeatedly.

Unexpected changes: Actions happening on focus or typing without user confirmation.

What level of WCAG should I target?

WCAG 2.1 Level AA is the most common target and is required by many regulations. Level A is the minimum; Level AAA is ideal but not always practical for all content.

Is accessibility just about screen readers?

No. Accessibility covers visual, auditory, motor, and cognitive considerations. Screen reader compatibility is one part. Keyboard access, color contrast, cognitive load, and motor accessibility are equally important.

How do I retrofit accessibility into an existing product?

Start with an audit to identify issues. Prioritize by severity and frequency of use. Fix critical keyboard and screen reader issues first. Add accessibility to your development process going forward.

What's the difference between accessibility and usability?

Accessibility ensures people with disabilities can use the product. Usability is about how easy the product is to use. They overlap significantly - accessible design is usually more usable for everyone.

Do ARIA attributes make things accessible?

ARIA can help when native HTML isn't sufficient, but misused ARIA often makes things worse. The first rule of ARIA: don't use ARIA if you can use native HTML elements instead.

Related resources