Accessibility Testing Tools — Complete Guide

In this tutorial, you will learn about Accessibility Testing Tools. We cover key concepts, practical examples, and best practices to help you master this topic.

Accessibility testing tools range from automated scanners like axe DevTools, Lighthouse, and WAVE to manual testing approaches including screen reader testing, keyboard navigation, and color contrast analyzers.

What You'll Learn

• Categories of accessibility testing tools
• Automated testing with axe DevTools and Lighthouse
• Manual testing with keyboard and screen readers
• Contrast checking tools
• Accessibility browser extensions
• Integrating accessibility testing into CI/CD

Why It Matters

• Automated tools catch 30-50 percent of accessibility issues
• Manual testing catches issues automated tools miss
• Regular testing prevents accessibility regressions
• Testing tools help educate developers about accessibility

Real-World Use

• A CI pipeline runs axe-core on every Pull Request
• A QA team uses WAVE for quick page audits
• A developer uses Lighthouse in Chrome DevTools
• An accessibility specialist tests with NVDA and JAWS

flowchart LR
  A[Testing Strategy] --> B[Automated]
  A --> C[Manual]
  A --> D[User Testing]
  B --> E[axe, Lighthouse, WAVE]
  C --> F[Keyboard, Screen Reader]
  D --> G[Real Users with Disabilities]

Testing Categories

Accessibility testing is not a single activity. It requires multiple approaches:

Automated testing uses software to scan pages for known issues. Fast, consistent, but limited in scope.

Manual testing involves human testers using keyboard navigation, screen readers, and visual inspection. Slower but catches more issues.

User testing involves people with disabilities testing your site. Most valuable but most resource-intensive.

Automated Testing Tools

axe DevTools: Browser extension and library that finds WCAG violations. Considered the industry standard. Integrates with testing frameworks.

Lighthouse: Built into Chrome DevTools. Audits accessibility, performance, SEO, and more. Free and easy to use.

WAVE: Browser extension from WebAIM. Visual overlay shows issues directly on the page.

Accessibility Insights: Microsoft's tool with both automated and guided manual testing.

Code Example: Automated Testing with axe-core

// Running axe-core in a test suite (with Jest)
import axe from 'axe-core';

describe('Accessibility tests', () => {
    it('should have no accessibility violations on the homepage', async () => {
        // Navigate to the page
        await page.goto('https://example.com');

        // Run axe-core
        const results = await axe.run(page, {
            runOnly: {
                type: 'tag',
                values: ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa']
            }
        });

        // Assert no violations
        expect(results.violations).toHaveLength(0);
    });

    it('should have no violations on the product page', async () => {
        await page.goto('https://example.com/products');

        const results = await axe.run(page);

        if (results.violations.length > 0) {
            console.log('Violations found:');
            results.violations.forEach(violation => {
                console.log(`- ${violation.id}: ${violation.description}`);
                violation.nodes.forEach(node => {
                    console.log(`  Target: ${node.target}`);
                    console.log(`  Fix: ${node.failureSummary}`);
                });
            });
        }

        expect(results.violations).toHaveLength(0);
    });
});

Expected output: The test reports any WCAG violations with the specific element, the criterion violated, and guidance for fixing it. A passing test means no detectable violations were found.

Code Example: Manual Testing Checklist

<!-- Manual testing template -->
<h1>Accessibility Testing Checklist</h1>

<h2>Keyboard Testing</h2>
<ul>
    <li><input type="checkbox"> Tab through all interactive elements in logical order</li>
    <li><input type="checkbox"> All interactive elements have visible focus indicators</li>
    <li><input type="checkbox"> No keyboard traps (focus cannot leave a component)</li>
    <li><input type="checkbox"> Enter/Space activates buttons and links</li>
    <li><input type="checkbox"> Escape closes modals, dropdowns, and dialogs</li>
    <li><input type="checkbox"> Arrow keys work for tab panels, menus, sliders</li>
    <li><input type="checkbox"> Skip link is first focusable element</li>
</ul>

<h2>Screen Reader Testing</h2>
<ul>
    <li><input type="checkbox"> Page structure announced (landmarks, headings)</li>
    <li><input type="checkbox"> All images have appropriate alt text</li>
    <li><input type="checkbox"> Form inputs have associated labels</li>
    <li><input type="checkbox"> Dynamic content changes are announced</li>
    <li><input type="checkbox"> Error messages are announced</li>
    <li><input type="checkbox"> Custom widgets announce their role and state</li>
    <li><input type="checkbox"> Links make sense when read out of context</li>
</ul>

<h2>Visual Testing</h2>
<ul>
    <li><input type="checkbox"> Color contrast meets WCAG AA (4.5:1 for text)</li>
    <li><input type="checkbox"> Information is not conveyed by color alone</li>
    <li><input type="checkbox"> Text is readable at 200% zoom</li>
    <li><input type="checkbox"> Focus indicators are visible</li>
    <li><input type="checkbox"> Touch targets are at least 44x44px</li>
</ul>

Expected output: A structured checklist that ensures consistent manual testing across the team. Each item corresponds to a specific WCAG criterion.

Code Example: CI/CD Integration

# GitHub Actions workflow for accessibility testing
name: Accessibility CI

on:
  pull_request:
    branches: [main]

jobs:
  a11y-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Build project
        run: npm run build

      - name: Start server
        run: npm run serve & sleep 3

      - name: Run axe-core tests
        run: npm run test:a11y

      - name: Run Lighthouse CI
        run: |
          npm install -g @lhci/cli
          lhci autorun

      - name: Check color contrast
        run: npm run test:contrast

      - name: Report results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: a11y-reports
          path: reports/

Expected output: Every pull request triggers automated accessibility tests. If violations are introduced, the PR is blocked until fixed. Reports are available as artifacts.

Common Mistakes

1. Relying only on automated tools — Automated tools catch only 30-50 percent of accessibility issues. Manual testing is essential.
2. Testing only one page — Accessibility issues vary across pages. Test all unique page templates.
3. Not testing with actual screen readers — Browser extensions simulate screen readers but do not catch all issues. Test with NVDA, VoiceOver, or JAWS.
4. Ignoring violations with low severity — Even minor violations compound and create a poor experience.
5. Not testing dynamically loaded content — SPAs and AJAX content may load without triggering accessibility checks.
6. Testing only at the end of development — Fixing accessibility late in development is expensive. Test from the start.
7. Not establishing a baseline — Without a baseline, you cannot measure improvement or catch regressions.

Practice Questions

1. What percentage of accessibility issues do automated tools typically catch? 30-50 percent. The remaining issues require manual testing.
2. What is the purpose of the axe-core library? It is a JavaScript accessibility testing engine that programmatically checks pages for WCAG violations.
3. Name three categories of accessibility testing and give an example of each. Automated (axe DevTools), manual (keyboard navigation), user testing (testing with people with disabilities).
4. Why should accessibility testing be integrated into CI/CD? To catch accessibility regressions before they reach production, when they are cheaper and faster to fix.
5. Challenge: Set up an automated accessibility testing pipeline for a small project. Use axe-core for WCAG violation detection, Lighthouse for performance and accessibility scoring, and a contrast checking tool. Run all tests on pull requests and generate a combined report.

FAQ

Mini Project

Create a comprehensive accessibility testing plan for a multi-page website. The plan must include: automated testing with axe-core (script that scans all pages), manual keyboard testing checklist (at least 15 items), screen reader testing flow (test with NVDA covering 3 key user journeys), color contrast audit (check all color combinations), responsive zoom testing (at 200 percent), and CI/CD integration configuration. Execute the plan on a sample site and produce a report with at least 10 findings (5 automated, 5 manual) with severity ratings and recommended fixes.

What's Next

Continue with Lesson 26: Automated Accessibility Testing for an in-depth guide on integrating testing into your development workflow.