Accessibility Testing Checklist

Table of Contents
1. Accessibility Testing Checklist
2. Understanding Accessibility Testing
3. Perceivable Content
4. Operable Interface
5. Understandable Content
6. Robust and Compatible
7. Mobile-Specific Accessibility
8. Testing Tools and Methods
9. Common Accessibility Issues to Avoid
10. Creating Your Own Testing Workflow
11. Documentation and Reporting
12. Continuous Improvement
View more

Accessibility Testing Checklist

Imagine you've just designed a beautiful website or mobile app. The colors are perfect, the layout is stunning, and everything works smoothly on your device. But then you realize: can everyone actually use it? What about people who are blind, colorblind, or have motor disabilities? What about someone using only a keyboard or a screen reader?

This is where accessibility testing comes in. An accessibility testing checklist is like a pre-flight checklist for pilots-it ensures that nothing critical is missed before your design goes live. In this document, we'll walk through the essential items you need to check to make sure your web or mobile designs are truly inclusive and accessible to all users.

Understanding Accessibility Testing

Accessibility testing is the process of evaluating whether your digital product can be used by people with various disabilities. These disabilities can be:

• Visual: blindness, low vision, color blindness
• Auditory: deafness or hearing impairment
• Motor: difficulty using a mouse or touchscreen
• Cognitive: learning disabilities, memory issues, or attention disorders

Think of accessibility testing as building a building with multiple entrances. Sure, stairs work for most people, but what about someone in a wheelchair? That's why we add ramps, elevators, and automatic doors. Similarly, digital accessibility ensures everyone has a way to access your content.

Perceivable Content

The first principle of accessibility is that information must be perceivable-users must be able to perceive the content through at least one of their senses. Let's break down what to check.

Text Alternatives for Images

Every image, icon, or graphic that conveys information needs a text alternative. This is crucial for screen reader users who cannot see the images.

What to check:

• Does every meaningful image have an alt attribute?
• Is the alt text descriptive and meaningful? (e.g., "Submit button" instead of just "button")
• Are decorative images marked with empty alt text (alt="") so screen readers skip them?
• Do complex images like charts or infographics have longer descriptions available?
• Do icons that function as buttons have appropriate labels?

Example: An image of a shopping cart icon should have alt="Shopping cart" or alt="View shopping cart" rather than alt="icon.png" or no alt text at all.

Captions and Transcripts for Multimedia

Audio and video content needs alternatives for people who cannot hear or see them.

What to check:

• Do all videos have captions (not just subtitles for foreign languages)?
• Are captions synchronized accurately with the audio?
• Do videos include audio descriptions for important visual information?
• Are transcripts available for audio-only content like podcasts?
• Can users control media playback (play, pause, stop)?

Color and Contrast

Color alone should never be the only way to convey information, because some users are colorblind or have low vision.

What to check:

• Is the contrast ratio between text and background at least 4.5:1 for normal text?
• Is the contrast ratio at least 3:1 for large text (18pt or 14pt bold and larger)?
• Are interactive elements like buttons and form fields visually distinct from the background?
• Is information conveyed by color also indicated in another way (like text, icons, or patterns)?
• Can users with color blindness distinguish between different states (like error messages in red)?

Example: Instead of only using red text to show an error, combine it with an error icon and explicit text like "Error: Please enter a valid email address."

Text Resizing and Responsive Design

Many users need to increase text size to read comfortably.

What to check:

• Can text be resized up to 200% without loss of content or functionality?
• Does the layout adapt properly when text is enlarged?
• Is text readable and functional at different screen sizes and orientations?
• Are font sizes specified in relative units (like em or rem) rather than fixed pixels?

Operable Interface

An operable interface means users can actually interact with all the controls and navigation. This is especially important for people who cannot use a mouse or touchscreen.

Keyboard Accessibility

Many users navigate websites using only a keyboard due to motor disabilities or personal preference. Every interactive element must be accessible via keyboard.

What to check:

• Can you navigate the entire site using only the Tab, Enter, Space, and arrow keys?
• Is there a visible focus indicator showing which element is currently selected?
• Is the focus indicator easy to see (good contrast with background)?
• Does the tab order follow a logical, intuitive sequence?
• Can users access all dropdown menus, modals, and pop-ups with keyboard alone?
• Can keyboard focus get trapped in any component (like a modal dialog)?
• Are there skip links to bypass repetitive content like navigation menus?

Testing tip: Unplug your mouse and try to complete common tasks on your site using only the keyboard. If you get stuck, so will your users.

Touch Target Size

For mobile interfaces, touch targets need to be large enough for people with motor difficulties to tap accurately.

What to check:

• Are all interactive elements at least 44×44 pixels (or CSS pixels) in size?
• Is there adequate spacing between touch targets to prevent accidental taps?
• Can gestures be performed with a single pointer (avoiding multi-finger requirements)?
• Are complex gestures (like swiping or pinching) accompanied by simple alternatives?

Timing and Motion

Some users need more time to read or interact with content, and some are sensitive to motion and animation.

What to check:

• Can users extend or disable time limits on timed content (like session timeouts)?
• Can users pause, stop, or hide moving, blinking, or auto-updating content?
• Are users warned before time limits expire?
• Can animations be disabled or reduced for users who prefer reduced motion?
• Does the site avoid content that flashes more than three times per second (to prevent seizures)?

Navigation and Wayfinding

Users should always know where they are and how to get where they want to go.

What to check:

• Are navigation menus consistent across the site?
• Do pages have clear, descriptive headings that create a logical structure?
• Are there multiple ways to find content (like search, sitemap, or navigation)?
• Do links have descriptive text rather than generic phrases like "click here"?
• Is the current page or location clearly indicated in navigation menus?

Understandable Content

Content must be understandable both in terms of readability and predictability. Users should be able to comprehend information and know how the interface will behave.

Language and Readability

What to check:

• Is the primary language of the page identified in the HTML (using the lang attribute)?
• Are language changes within the page marked up (for passages in different languages)?
• Is content written in clear, simple language appropriate for the audience?
• Are abbreviations and acronyms explained on first use?
• Are unusual words, jargon, or technical terms defined or explained?

Example: <html lang="en"> tells assistive technologies that the page is in English, so they can pronounce words correctly.

Predictable Behavior

Interfaces should behave in ways users expect. Unpredictable changes can confuse or disorient users, especially those with cognitive disabilities.

What to check:

• Does focusing on an element cause unexpected context changes (like automatically submitting forms)?
• Does changing a setting or input cause unexpected navigation or pop-ups?
• Are navigation mechanisms consistent in position and behavior across pages?
• Are components that appear on multiple pages identified consistently?
• Do hover effects and focus states behave consistently?

Input Assistance

Forms can be challenging for many users. Good input assistance helps prevent and correct errors.

What to check:

• Are all form fields clearly labeled?
• Do labels remain visible even when fields are filled in?
• Are required fields clearly indicated?
• Are error messages clear, specific, and helpful?
• Do error messages suggest how to fix the problem?
• Can users review and correct information before final submission (especially for legal or financial transactions)?
• Are input formats clearly explained (like date formats or password requirements)?
• Does the site provide autocomplete for common fields (like name, email, address)?

Bad example: "Error: Invalid input"
Good example: "Error: Email address must include an @ symbol. Please enter a valid email address like name@example.com"

Robust and Compatible

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

Semantic HTML

Using proper HTML elements helps assistive technologies understand and present content correctly.

What to check:

• Are proper semantic HTML elements used (like <nav>, <main>, <header>, <footer>, <article>)?
• Are headings (<h1> through <h6>) used to create a logical document structure?
• Do headings follow a logical hierarchy without skipping levels?
• Are lists marked up with proper <ul>, <ol>, or <dl> elements?
• Are data tables marked up with <table>, <th>, and <td> elements?
• Do buttons use <button> elements rather than styled divs?
• Do links use <a> elements with proper href attributes?

ARIA (Accessible Rich Internet Applications)

ARIA attributes provide additional information to assistive technologies when standard HTML isn't sufficient. However, proper HTML should always be the first choice.

What to check:

• Are ARIA roles used appropriately to identify regions and widgets?
• Are ARIA properties and states used to convey information not available from HTML alone?
• Are dynamic content updates announced to screen readers using aria-live regions?
• Do custom controls have appropriate role, state, and property attributes?
• Are ARIA labels used to provide accessible names where needed?
• Is ARIA used correctly without overriding native HTML semantics?

Remember: The first rule of ARIA is "Don't use ARIA." Use native HTML elements whenever possible, and only add ARIA when HTML alone cannot convey the necessary information.

Assistive Technology Compatibility

What to check:

• Does the site work with major screen readers (like NVDA, JAWS, VoiceOver, TalkBack)?
• Can users navigate and understand content using screen readers?
• Do screen readers announce dynamic content changes?
• Does the site work with browser zoom and text resizing features?
• Is the HTML valid and free of parsing errors that could confuse assistive technologies?
• Are all interactive elements properly exposed to accessibility APIs?

Mobile-Specific Accessibility

Mobile devices introduce unique accessibility considerations beyond standard web accessibility.

Screen Reader Support

What to check:

• Does the app work with native mobile screen readers (VoiceOver on iOS, TalkBack on Android)?
• Are all elements properly labeled for screen readers?
• Is the reading order logical when navigating with swipe gestures?
• Are decorative elements hidden from screen readers?
• Do images of text have appropriate alternative text?

Touch and Gesture Accessibility

What to check:

• Can all functionality be accessed without complex gestures?
• Are gesture-based actions available through alternative means (like buttons)?
• Can users undo accidental gestures or actions?
• Does the app support device accessibility features like Assistive Touch?

Orientation and Layout

What to check:

• Does the app support both portrait and landscape orientations?
• Is content readable and functional in both orientations?
• Does the interface adapt to different screen sizes?
• Can users with low vision use system-level zoom features?

Testing Tools and Methods

Having a checklist is great, but you also need the right tools and methods to actually perform accessibility testing.

Automated Testing Tools

Automated tools can catch many common accessibility issues quickly, but they typically only identify 25-30% of all accessibility problems.

Common automated testing tools:

• Browser extensions: WAVE, axe DevTools, Lighthouse
• Color contrast checkers: WebAIM Contrast Checker, Contrast Ratio
• HTML validators: W3C Markup Validation Service
• Screen reader testing tools: built-in screen readers or third-party software

What automated tools can check:

• Missing alt text on images
• Insufficient color contrast
• Missing form labels
• Invalid HTML markup
• Missing page titles or language attributes
• Improper heading hierarchy
• Missing ARIA attributes on custom widgets

Manual Testing

Manual testing is essential because many accessibility issues cannot be detected automatically.

Keyboard testing:

• Disconnect your mouse
• Navigate through the entire site using only Tab, Shift+Tab, Enter, Space, and arrow keys
• Verify that focus is always visible
• Check that the tab order makes logical sense
• Ensure you can access all interactive elements
• Verify you can close modals and pop-ups

Screen reader testing:

• Use a screen reader to navigate your site (VoiceOver on Mac, NVDA on Windows, TalkBack on Android)
• Listen to how content is announced
• Verify that all important information is conveyed
• Check that dynamic updates are announced
• Ensure navigation makes sense when you can't see the screen

Visual testing:

• Zoom to 200% and verify all content is still accessible
• Test with high contrast mode enabled
• Simulate color blindness using browser extensions
• Test on different screen sizes and orientations

User Testing with People with Disabilities

The most valuable testing comes from real users with disabilities. They will discover issues that tools and guidelines might miss.

What to consider:

• Include users with diverse disabilities in your testing
• Watch how they actually interact with your interface
• Listen to their feedback about pain points and barriers
• Don't assume you know what works-let users show you
• Test early and often throughout the design process

Common Accessibility Issues to Avoid

Based on real-world accessibility audits, here are the most common issues found in web and mobile designs.

Images and Graphics

• Missing or poor alt text on images
• Decorative images not hidden from screen readers
• Important information conveyed only through images
• Text embedded in images without alternatives
• Complex charts without detailed descriptions

Color and Contrast

• Insufficient contrast between text and background
• Information conveyed by color alone
• Poor contrast in different states (hover, focus, disabled)
• Light gray text on white backgrounds
• Invisible or barely visible focus indicators

Keyboard and Focus

• Elements not reachable by keyboard
• No visible focus indicator
• Illogical tab order
• Keyboard focus trapped in components
• Custom controls that don't respond to standard keyboard commands

Forms and Input

• Form fields without labels
• Labels that disappear when fields are filled
• Unclear or missing error messages
• Required fields not indicated
• No instructions for expected input formats
• Time limits without ability to extend them

Structure and Semantics

• Improper or missing heading structure
• Skipped heading levels (like going from h2 to h4)
• Using divs and spans instead of semantic HTML
• Tables used for layout instead of data
• Missing or incorrect ARIA roles and attributes
• Missing page language declaration

Multimedia

• Videos without captions
• No transcripts for audio content
• Auto-playing media without controls
• Missing audio descriptions for important visual content
• Media players not keyboard accessible

Creating Your Own Testing Workflow

An effective accessibility testing workflow integrates checks throughout the design and development process rather than leaving testing until the end.

During Design Phase

• Check color contrast in design mockups
• Ensure touch targets meet minimum size requirements
• Design visible focus states for all interactive elements
• Plan for text alternatives and captions
• Create logical heading hierarchies
• Consider keyboard navigation patterns

During Development Phase

• Use semantic HTML elements
• Add appropriate ARIA attributes
• Implement keyboard navigation
• Run automated accessibility tests
• Validate HTML markup
• Test with browser zoom and text resizing

Before Launch

• Perform comprehensive manual testing
• Test with screen readers
• Complete full keyboard navigation testing
• Review all automated test results
• Conduct user testing with people with disabilities if possible
• Document known issues and remediation plans

After Launch

• Monitor user feedback about accessibility barriers
• Conduct periodic accessibility audits
• Test new features before adding them
• Keep up with changing accessibility standards
• Continue user testing and iteration

Documentation and Reporting

Good documentation helps track accessibility issues and ensure they get resolved.

What to Document

Prioritizing Issues

Critical priority:

• Complete blockers that prevent access to core functionality
• Issues affecting many users
• Legal compliance requirements

High priority:

• Significant barriers that make tasks difficult but not impossible
• Issues affecting common user flows
• Multiple WCAG violations in one area

Medium priority:

• Issues that affect usability but have workarounds
• Best practice violations that don't block access
• Issues affecting less common features

Low priority:

• Minor enhancements and optimizations
• Issues with minimal user impact
• Nice-to-have improvements

Continuous Improvement

Accessibility is not a one-time checklist-it's an ongoing commitment. As you add new features, update content, or redesign interfaces, you need to continuously test and improve accessibility.

Building an accessibility culture:

• Make accessibility everyone's responsibility, not just one person's job
• Include accessibility in design reviews and code reviews
• Provide accessibility training for designers and developers
• Celebrate accessibility wins and learn from mistakes
• Stay informed about new accessibility techniques and standards
• Listen to feedback from users with disabilities

Remember, the goal of accessibility testing isn't just to pass an audit or check boxes on a list. The goal is to create digital experiences that truly work for everyone, regardless of their abilities. Every accessibility improvement you make opens your product to more people and makes the web a more inclusive place.

Start with this checklist, adapt it to your specific needs, and make accessibility testing a natural part of your design and development process. Your users-all of them-will thank you.