Accessibility Checklist

This checklist helps you evaluate and improve the accessibility of digital products. It's organized by WCAG's four principles: Perceivable, Operable, Understandable, and Robust.

Last updated: January 2026

Why accessibility matters

Accessible design benefits everyone—not just people with permanent disabilities. Situational limitations (bright sunlight, noisy environment), temporary impairments (broken arm, eye infection), and age-related changes affect us all.

Beyond the moral case, accessibility is often legally required. More importantly, it's good design. Accessible products tend to be clearer, more usable, and more robust for everyone.

For comprehensive guidance on web accessibility principles and techniques, refer to the W3C Web Accessibility Initiative (WAI) resources.

Perceivable

Users must be able to perceive the information presented.

Text alternatives

• All images have appropriate alt text that conveys meaning (or empty alt for decorative images)
• Complex images (charts, diagrams) have extended descriptions
• Icons that convey meaning have text alternatives or labels
• Form inputs have visible labels (not just placeholders)

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

Time-based media

• Videos have captions
• Audio content has transcripts
• Live audio has real-time captions where feasible

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

Adaptable content

• Content structure is conveyed through proper headings (H1, H2, H3)
• Lists use proper list markup
• Tables use proper header cells and structure
• Reading order makes sense when CSS is disabled
• Instructions don't rely solely on sensory characteristics (color, shape, position)

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

Distinguishable

• Color is not the only way information is conveyed
• Text has sufficient contrast ratio (4.5:1 for normal text, 3:1 for large text)
• Non-text elements have sufficient contrast (3:1 for UI components)
• Text can be resized to 200% without loss of functionality
• Content reflows at 320px width without horizontal scrolling
• Audio that plays automatically can be stopped or volume controlled

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

• All functionality is available via keyboard
• Focus is visible on all interactive elements
• Focus order follows a logical sequence
• No keyboard traps (focus can always move away)
• Keyboard shortcuts don't conflict with assistive technology

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

Enough time

• Time limits can be extended or turned off
• Users are warned before session timeouts with option to extend
• Auto-updating content can be paused, stopped, or hidden

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

Seizures and physical reactions

• Nothing flashes more than 3 times per second
• Motion animation can be disabled (respects prefers-reduced-motion)

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

Navigable

• Skip link allows bypassing repeated content
• Pages have descriptive titles
• Focus order is logical and intuitive
• Link purpose is clear from link text (or programmatically determinable)
• Multiple ways to find pages (navigation, search, site map)
• Headings and labels describe content or purpose

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

• Pointer gestures have single-pointer alternatives
• Pointer cancellation is supported (down event doesn't trigger action)
• Touch targets are at least 44×44 CSS pixels
• Dragging actions have non-dragging alternatives

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

Understandable

Users must be able to understand the information and interface.

Readable

• Language of page is programmatically identified
• Language changes within content are marked
• Unusual words or jargon are defined
• Abbreviations are expanded on first use

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

Predictable

• Focus doesn't trigger unexpected context changes
• Input doesn't trigger unexpected context changes without warning
• Navigation is consistent across pages
• Components are identified consistently

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

Input assistance

• Input errors are clearly identified and described in text
• Labels and instructions are provided for user input
• Error suggestions are provided when possible
• Legal/financial submissions can be reviewed, confirmed, or reversed
• Context-sensitive help is available

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

• HTML validates without significant errors
• Name, role, and value are programmatically determinable for all UI components
• Status messages are announced without receiving focus (using ARIA live regions)

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

• UX Basics
• Forms Patterns
• Error States Pattern
• Navigation Patterns