Accessibility Testing: WCAG, POUR Principles, Tools & Techniques

Parul Dhingra13+ Years ExperienceHire Me

Senior Quality Analyst

Updated: 6/24/2025

Accessibility testing ensures that software applications work for everyone, including people who use screen readers, keyboard navigation, voice control, and other assistive technologies. This is not optional - accessibility is a legal requirement in many jurisdictions and affects approximately 15% of the global population living with some form of disability.

This guide covers the practical aspects of accessibility testing: what standards to follow, which tools to use, and how to test effectively.

What is Accessibility Testing

Accessibility testing validates that applications can be used effectively by people with disabilities. This includes testing with:

• Screen readers that convert text to speech for blind users
• Keyboard navigation for users who cannot use a mouse
• Screen magnifiers for users with low vision
• Voice recognition software for users with motor impairments
• Switch devices for users with severe motor limitations

Unlike traditional usability testing that focuses on general user experience, accessibility testing specifically validates that assistive technologies can interpret and interact with your application correctly.

Accessibility testing requires understanding how assistive technologies parse HTML, interpret ARIA attributes, and navigate document structures. A visually appealing interface can be completely unusable for screen reader users if the underlying code lacks proper semantics.

What Makes Accessibility Testing Different

Traditional functional testing verifies that features work when interacted with via mouse and keyboard in standard ways. Accessibility testing expands this to verify:

• Screen readers announce content in a logical, meaningful order
• Keyboard users can access all interactive elements
• Users who cannot perceive color still receive all information
• Users who need more time can complete tasks without timeout issues
• Content remains usable when zoomed to 200% or higher

WCAG Guidelines Explained

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility. WCAG 2.1 is the current widely-adopted version, with WCAG 2.2 adding additional success criteria.

Conformance Levels

WCAG defines three conformance levels:

Level A - Minimum accessibility. These are non-negotiable requirements that, if not met, make content impossible for some users to access. Examples:

• All images have alternative text
• Content does not cause seizures
• Keyboard access is available for all functionality

Level AA - Standard compliance target. This level is required by most accessibility laws and provides a good user experience for most users with disabilities. Adds requirements like:

• Color contrast of at least 4.5:1 for normal text
• Text can be resized up to 200% without loss of functionality
• Multiple ways to navigate content

Level AAA - Enhanced accessibility. Not required for entire sites but recommended for specific content or audiences. Includes:

• Enhanced color contrast of 7:1
• Sign language for all audio content
• More detailed explanations for complex content

WCAG 2.1 vs 2.2

WCAG 2.2, released in 2023, added nine new success criteria primarily addressing:

• Mobile and touch accessibility
• Users with cognitive disabilities
• Users with low vision

Key additions include requirements for consistent help mechanisms, accessible authentication methods, and minimum target sizes for interactive elements.

The POUR Principles

WCAG organizes all success criteria around four principles known as POUR. Understanding these principles helps you think about accessibility systematically rather than as a checklist of disconnected requirements.

Perceivable

Users must be able to perceive the information being presented. This does not require all users to perceive content through the same sense - it requires that content be available through at least one accessible means.

Key requirements:

• Text alternatives: Images need alt text describing their content or function. Decorative images should have empty alt attributes (alt="").
• Captions and transcripts: Video content needs synchronized captions. Audio-only content needs transcripts.
• Color independence: Information cannot be conveyed through color alone. Error states, required fields, and status indicators need additional visual cues.
• Contrast ratios: Text must have sufficient contrast against its background - 4.5:1 for normal text, 3:1 for large text at Level AA.

Testing approach:

1. Disable images - can you understand all content?
2. View page in grayscale - is information still clear?
3. Check contrast ratios using browser dev tools or WAVE
4. Play videos without sound - are captions accurate and synchronized?

Operable

Users must be able to operate the interface. This means all functionality must be available to users regardless of input method.

Key requirements:

• Keyboard accessibility: Every interactive element must be operable with keyboard alone. This includes custom widgets, modal dialogs, and dropdown menus.
• Focus visibility: Users must always see which element has keyboard focus. Default browser focus indicators are often insufficient.
• No keyboard traps: Users must be able to navigate away from any element using standard keyboard commands.
• Enough time: If timeouts exist, users need ability to extend or disable them.
• No seizure risk: Content must not flash more than three times per second.

Testing approach:

1. Unplug mouse and navigate entire application with keyboard
2. Tab through all pages - is focus order logical?
3. Can you always see where focus is?
4. Can you escape from modal dialogs with Escape key?
5. Can you access all dropdown menu options?

Understandable

Users must be able to understand both the content and how to operate the interface.

Key requirements:

• Readable content: Language of the page must be programmatically determinable. Text should be as clear as possible.
• Predictable behavior: Navigation is consistent across pages. Components behave consistently.
• Input assistance: Forms clearly identify errors and provide suggestions for correction. Required fields are marked before submission.

Testing approach:

1. Check that page language is set in HTML (<html lang="en">)
2. Submit forms with errors - are messages clear and helpful?
3. Navigate between pages - is navigation consistent?
4. Do similar components behave the same way throughout?

Robust

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

Key requirements:

• Valid HTML: Markup should follow specifications. IDs must be unique. Elements must be properly nested.
• Name, role, value: Custom controls must expose their name, role, current state, and properties to assistive technologies through ARIA when native HTML semantics are insufficient.

Testing approach:

1. Validate HTML for parsing errors
2. Check custom widgets have appropriate ARIA roles and states
3. Test with multiple screen readers - does content make sense?

Types of Disabilities and Testing Considerations

Effective accessibility testing requires understanding how different users interact with technology.

Visual Impairments

Blindness: Users rely entirely on screen readers. They navigate by headings, landmarks, and links. They cannot see visual layouts or spatial relationships.

Testing focus:

• Heading hierarchy is logical (h1, h2, h3 in order)
• Images have meaningful alt text
• Links make sense out of context ("Read more" is problematic; "Read more about accessibility testing" is better)
• Tables have proper headers and scope attributes

Low vision: Users may use screen magnifiers, high contrast modes, or simply zoom their browser significantly.

Testing focus:

• Content reflows at 400% zoom without horizontal scrolling
• Text spacing can be adjusted without breaking layouts
• High contrast mode does not hide content

Color blindness: Users cannot distinguish certain color combinations, most commonly red and green.

Testing focus:

• Information is not conveyed by color alone
• Error states have icons or text, not just red color
• Charts and graphs use patterns in addition to colors

Auditory Impairments

Deafness and hearing loss: Users cannot access audio content without alternatives.

Testing focus:

• Videos have accurate, synchronized captions
• Audio-only content has transcripts
• Audio alerts have visual alternatives

Motor Impairments

Limited mobility: Users may navigate with keyboard, voice control, eye tracking, or switch devices.

Testing focus:

• All functionality accessible via keyboard
• Click targets are large enough (at least 44x44 pixels recommended)
• Drag-and-drop has keyboard alternatives
• Time limits can be extended

Cognitive Disabilities

Various conditions: Including dyslexia, ADHD, memory issues, and learning disabilities.

Testing focus:

• Content uses clear, simple language
• Instructions are explicit
• Error messages are helpful and not blaming
• Consistent navigation reduces cognitive load
• Users can pause, stop, or hide moving content

Automated Accessibility Testing Tools

Automated tools provide a quick initial assessment but cannot catch all accessibility issues. Use them as a starting point, not a complete solution.

axe-core and axe DevTools

axe-core is an open-source accessibility testing engine used by many other tools and browser extensions.

What it tests:

• Missing alt text
• Color contrast violations
• Missing form labels
• Invalid ARIA usage
• Document structure issues

How to use:

Browser extension approach:

1. Install axe DevTools extension (Chrome or Firefox)
2. Open DevTools and navigate to the axe tab
3. Click "Scan all of my page"
4. Review issues by impact level (critical, serious, moderate, minor)

Command line / CI integration:

// Using axe-core with Playwright
const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;
 
test('homepage has no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

WAVE (Web Accessibility Evaluation Tool)

WAVE provides visual feedback by inserting icons and indicators directly into the page.

What it tests:

• Similar issues to axe
• Also shows page structure (headings, landmarks, ARIA)
• Highlights reading and tab order

How to use:

1. Install WAVE browser extension
2. Click the extension icon on any page
3. Review icons inserted into the page
4. Red icons indicate errors, yellow indicate warnings
5. Use the Details tab for full issue list

Strengths:

• Visual representation helps understand issues in context
• Shows document structure clearly
• Good for learning accessibility concepts

Lighthouse

Built into Chrome DevTools, Lighthouse provides accessibility scoring alongside performance and SEO metrics.

How to use:

1. Open Chrome DevTools (F12)
2. Go to Lighthouse tab
3. Check "Accessibility" category
4. Click "Analyze page load"
5. Review score and failed audits

Limitations:

• Runs fewer tests than axe or WAVE
• Score can be misleading - 100 does not mean fully accessible
• Best used as quick overview, not comprehensive audit

Pa11y

Pa11y is a command-line tool useful for CI/CD integration and batch testing.

# Install
npm install -g pa11y
 
# Test single page
pa11y https://example.com
 
# Test with specific standard
pa11y --standard WCAG2AA https://example.com
 
# Output as JSON for processing
pa11y --reporter json https://example.com

Tool Comparison

Automated tools catch approximately 30-50% of accessibility issues. They cannot verify that alt text is meaningful, that content makes sense in order, or that custom widgets are usable with assistive technologies. Manual testing is required for complete coverage.

Manual Testing Techniques

Manual testing fills the gaps that automation cannot cover. These techniques should be part of every accessibility test plan.

Keyboard Navigation Testing

Keyboard testing is the single most important manual test. Many accessibility issues affect keyboard users.

Basic navigation keys:

• Tab - move forward through interactive elements
• Shift + Tab - move backward
• Enter - activate links and buttons
• Space - activate buttons, toggle checkboxes
• Arrow keys - navigate within components (menus, radio groups, tabs)
• Escape - close modals and dropdowns

Testing checklist:

[ ] Can reach all interactive elements with Tab key
[ ] Tab order follows visual and logical order
[ ] Focus is always visible
[ ] Can activate all buttons and links with Enter or Space
[ ] Can escape from all modal dialogs
[ ] Dropdown menus are navigable with arrow keys
[ ] Custom widgets follow expected keyboard patterns
[ ] No keyboard traps exist
[ ] Skip links work and are visible on focus

Screen Reader Testing

Testing with actual screen readers reveals issues that other methods miss.

Common screen readers:

NVDA basic commands:

• Insert + Down Arrow - read continuously
• Tab - next interactive element
• H - next heading
• D - next landmark
• Insert + F7 - list all links
• Insert + F6 - list all headings

What to test:

[ ] Page title is announced when page loads
[ ] Headings create logical document outline
[ ] Images announce meaningful descriptions
[ ] Links announce their destination or purpose
[ ] Form fields announce their labels
[ ] Error messages are announced when they appear
[ ] Dynamic content changes are announced (ARIA live regions)
[ ] Tables announce row and column headers

Testing approach:

1. Turn off your monitor (or close your eyes)
2. Navigate the page using only keyboard and screen reader
3. Can you understand the page content?
4. Can you complete the main user tasks?
5. Is anything confusing or missing information?

Color Contrast Testing

While automated tools check contrast ratios, manual verification ensures nothing is missed.

Browser DevTools method:

1. Open DevTools
2. Select an element with text
3. Look at the Styles panel
4. Click the color swatch
5. View the contrast ratio and WCAG compliance indicators

Chrome color picker shows:

• Contrast ratio (e.g., 5.74)
• Lines indicating AA and AAA thresholds
• Whether current colors pass or fail each level

Testing text over images or gradients: Automated tools may miss text over variable backgrounds. Manually verify that text remains readable at all points where it overlaps.

Zoom and Reflow Testing

WCAG requires content to be usable at 200% zoom (Level AA) and 400% zoom (Level AAA for reflow).

Testing procedure:

1. Set browser zoom to 200%
2. Verify no horizontal scrolling needed for content
3. Check that all content is still visible
4. Verify interactive elements are still usable
5. Increase to 400% and repeat checks
6. Test with text-only zoom if browser supports it

Common failures:

• Content overflows containers and gets cut off
• Horizontal scrolling required to read text
• Interactive elements overlap or become unusable
• Fixed-position elements block content

Common Accessibility Issues and How to Fix Them

These issues appear repeatedly across websites and applications.

Missing or Poor Alt Text

Issue: Images without alt text, or alt text that does not convey meaningful information.

Bad:

<img src="chart.png">
<img src="ceo.jpg" alt="image">
<img src="icon.svg" alt="icon123.svg">

Good:

<img src="chart.png" alt="Bar chart showing sales increased 25% from Q1 to Q4 2024">
<img src="ceo.jpg" alt="Jane Smith, CEO">
<img src="icon.svg" alt="" role="presentation"> <!-- decorative -->

Guidelines:

• Describe the content and function, not the file
• For decorative images, use empty alt (alt="")
• For complex images, provide longer descriptions via aria-describedby or visible text

Missing Form Labels

Issue: Form inputs without programmatically associated labels.

Bad:

<input type="email" placeholder="Enter email">

Good:

<label for="email">Email address</label>
<input type="email" id="email" placeholder="name@example.com">

Or with visually hidden label:

<label for="search" class="visually-hidden">Search</label>
<input type="search" id="search" placeholder="Search...">

Insufficient Color Contrast

Issue: Text that does not have enough contrast against its background.

Requirements:

• Normal text (under 18pt or 14pt bold): 4.5:1 minimum
• Large text (18pt+ or 14pt+ bold): 3:1 minimum
• UI components and graphics: 3:1 minimum

Fixing:

• Darken text or lighten backgrounds
• Increase font weight for borderline cases
• Test with actual users - ratios are minimums, not ideals

Missing Keyboard Focus Indicators

Issue: No visible indication of which element has keyboard focus.

Bad:

:focus {
  outline: none;
}

Good:

:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}
 
:focus:not(:focus-visible) {
  outline: none;
}
 
:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Using :focus-visible shows focus indicators only for keyboard users, not mouse clicks.

Inaccessible Custom Components

Issue: Custom widgets that look like native controls but lack keyboard support and ARIA attributes.

Example: Accessible custom button:

<div
  role="button"
  tabindex="0"
  aria-pressed="false"
  onclick="toggleButton(this)"
  onkeydown="handleKeyDown(event, this)">
  Subscribe
</div>

function handleKeyDown(event, element) {
  if (event.key === 'Enter' || event.key === ' ') {
    event.preventDefault();
    toggleButton(element);
  }
}

Better approach: Use native HTML elements when possible. A <button> element handles all this automatically.

Missing Skip Links

Issue: Keyboard users must tab through entire navigation on every page.

Solution:

<body>
  <a href="#main-content" class="skip-link">Skip to main content</a>
  <nav>...</nav>
  <main id="main-content">...</main>
</body>

.skip-link {
  position: absolute;
  left: -10000px;
}
 
.skip-link:focus {
  position: static;
  left: auto;
}

Missing Language Declaration

Issue: Page language not specified, causing screen readers to use wrong pronunciation.

Fix:

<html lang="en">

For content in different languages within the page:

<p>The French word for hello is <span lang="fr">bonjour</span>.</p>

Integrating Accessibility Testing into Your Workflow

Accessibility is most effective when integrated throughout development, not added at the end.

Shift-Left Approach

Design phase:

• Include accessibility requirements in design specs
• Use accessible color palettes from the start
• Specify focus states for interactive elements
• Design with keyboard navigation in mind

Development phase:

• Use semantic HTML elements
• Include accessibility in code review checklist
• Run automated tests in local development
• Test keyboard navigation as you build

Testing phase:

• Include accessibility in test plans
• Combine automated and manual testing
• Test with real assistive technologies
• Include users with disabilities when possible

CI/CD Integration

Example GitHub Actions workflow:

name: Accessibility Tests
 
on: [push, pull_request]
 
jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Start application
        run: npm start &
      - name: Run axe tests
        run: npm run test:a11y

Example test script with Playwright and axe:

const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;
 
const pages = ['/', '/about', '/contact', '/products'];
 
for (const path of pages) {
  test(`${path} has no critical accessibility violations`, async ({ page }) => {
    await page.goto(path);
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa'])
      .analyze();
 
    const critical = results.violations.filter(
      v => v.impact === 'critical' || v.impact === 'serious'
    );
 
    expect(critical).toEqual([]);
  });
}

Definition of Done

Include accessibility criteria in your definition of done:

[ ] Passes automated accessibility scan with no critical/serious issues
[ ] Keyboard navigation tested and working
[ ] Screen reader tested (NVDA or VoiceOver)
[ ] Color contrast meets WCAG AA requirements
[ ] Focus indicators visible on all interactive elements

Mobile Accessibility Testing

Mobile accessibility has additional considerations beyond desktop web.

Touch Target Sizes

WCAG 2.2 requires minimum target sizes of 24x24 CSS pixels, with a recommendation of 44x44 pixels for better usability.

Testing:

• Measure touch targets in dev tools
• Test with users who have motor impairments
• Verify adequate spacing between targets

Mobile Screen Readers

iOS VoiceOver:

• Enable in Settings > Accessibility > VoiceOver
• Single tap to select, double tap to activate
• Swipe left/right to navigate elements
• Two-finger swipe up to read all

Android TalkBack:

• Enable in Settings > Accessibility > TalkBack
• Similar gestures to VoiceOver
• Double tap to activate
• Swipe to navigate

Mobile-Specific Issues

• Orientation lock - allow both portrait and landscape
• Motion activation - provide alternatives to shake or tilt
• Touch gestures - ensure alternatives for complex gestures
• Virtual keyboard - ensure it does not obscure inputs being filled

Legal Requirements and Compliance

Accessibility is legally required in many contexts.

United States

ADA (Americans with Disabilities Act): Courts have increasingly applied ADA to websites of businesses open to the public. No specific technical standard is mandated, but WCAG 2.1 Level AA is commonly referenced.

Section 508: Requires federal agencies and their contractors to make electronic information accessible. References WCAG 2.0 Level AA.

European Union

European Accessibility Act (EAA): Requires products and services including websites, mobile apps, and e-commerce to be accessible by June 2025.

EN 301 549: European standard referencing WCAG 2.1 Level AA.

Other Regions

• Canada: Accessibility for Ontarians with Disabilities Act (AODA), Accessible Canada Act
• UK: Equality Act 2010, Public Sector Bodies Accessibility Regulations
• Australia: Disability Discrimination Act

Legal requirements generally converge on WCAG 2.1 Level AA as the baseline standard. Meeting this standard addresses most legal compliance needs across jurisdictions.

Documentation

Maintain records of your accessibility efforts:

• Accessibility statement describing conformance level and known issues
• Testing documentation and remediation plans
• User feedback mechanisms and response procedures
• Regular audit schedules and results

Building an Accessibility Testing Strategy

Assessment

1. Audit current state using automated tools
2. Conduct manual testing of critical user journeys
3. Prioritize issues by impact and effort
4. Document baseline for measuring progress

Planning

1. Set target conformance level (typically WCAG 2.1 AA)
2. Allocate resources for remediation and ongoing testing
3. Train team members on accessibility basics
4. Establish accessibility champions in each team

Implementation

1. Fix critical issues in existing features
2. Integrate accessibility into new development
3. Add automated tests to CI/CD pipeline
4. Conduct regular manual testing sprints

Maintenance

1. Monitor for regressions with automated testing
2. Re-audit periodically (quarterly or after major releases)
3. Gather feedback from users with disabilities
4. Update practices as standards evolve

Accessibility testing is a continuous practice, not a one-time project. Building it into your standard development and testing processes ensures that your applications remain accessible as they evolve.

The investment pays off not just in legal compliance but in better experiences for all users. Accessible design principles - clear navigation, visible focus states, good contrast, proper form labels - improve usability for everyone.

Continue Reading

Frequently Asked Questions (FAQs) / People Also Ask (PAA)