Skip to content

Accessibility Testing — Automated a11y Testing (2026)

DodaTech Updated 2026-06-20 7 min read

In this tutorial, you'll learn about Accessibility Testingity" >}} Testing. We cover key concepts, practical examples, and best practices.

Accessibility testing (a11y testing) is the process of verifying that web applications are usable by people with disabilities — including those who rely on screen readers, keyboard navigation, or other assistive technologies.

What You'll Learn

You'll understand WCAG compliance levels, use axe-core and Lighthouse for automated audits, build a manual testing checklist, and integrate accessibility testing into your CI/CD pipeline.

Why Accessibility Testing Matters

Over 1 billion people worldwide have some form of disability. Inaccessible websites exclude users, risk legal liability, and lose business. Accessibility also benefits everyone — better contrast helps in sunlight, captions help in noisy environments. At DodaTech, Doda Browser underwent a full WCAG AA audit to ensure all users can navigate and use the browser effectively.

Accessibility Testing Learning Path

flowchart LR
  A[Testing Basics] --> B[Accessibility Testing]
  B --> C[Automated a11y Audits]
  B --> D[Manual Testing Checklist]
  B --> E[CI/CD Integration]
  style B fill:#f90,color:#fff

WCAG Compliance

The Web Content Accessibility Guidelines (WCAG) define four principles:

Principle Meaning Example
Perceivable Users can perceive the content Alt text on images, captions on video
Operable Users can operate the interface Keyboard navigation, enough time
Understandable Users can understand the content Clear labels, predictable behavior
Robust Content works across assistive tech Semantic HTML, ARIA attributes

WCAG Levels

Level Description Target
A Minimum accessibility Essential barriers removed
AA Acceptable accessibility Most common standard, legal requirements
AAA Highest accessibility Specialized, not always feasible

Automated a11y Testing with axe-core

axe-core is the most widely used accessibility testing engine, integrated into browsers and testing frameworks.

Using axe with Playwright

const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright');

test('homepage has no accessibility violations', async ({ page }) => {
  await page.goto('https://example.com');

  const results = await new AxeBuilder({ page }).analyze();

  expect(results.violations).toEqual([]);
});

When violations are found:

Expected: []
Received: [
  {
    id: 'color-contrast',
    impact: 'serious',
    description: 'Elements must have sufficient color contrast',
    nodes: [
      {
        target: ['.low-contrast-text'],
        failureSummary: 'Fix: Change color to meet ratio of 4.5:1'
      }
    ]
  }
]

Using axe with Cypress

// cypress/e2e/a11y.cy.js
describe('Accessibility tests', () => {
  beforeEach(() => {
    cy.visit('/');
    cy.injectAxe();
  });

  it('has no violations on the homepage', () => {
    cy.checkA11y();
  });

  it('has no violations on the login page', () => {
    cy.visit('/login');
    cy.checkA11y();
  });
});

Lighthouse a11y Audits

Chrome DevTools Lighthouse includes an accessibility audit that scores pages 0-100.

# CLI audit
npx lighthouse https://example.com --output=html --only-categories=accessibility

Lighthouse checks:

  • Background and foreground colors have sufficient contrast
  • <html> element has a [lang] attribute
  • Image elements have [alt] text
  • Links have discernible text
  • Form elements have associated labels
  • ARIA attributes follow valid values

Manual Testing Checklist

Automated tools catch ~30% of accessibility issues. Manual testing is essential.

Keyboard Navigation

- Tab through all interactive elements — is focus visible?
- Can you complete the primary action without a mouse?
- Are skip navigation links available?
- Does focus order match visual order?
- Can you close modals/popups with Escape?

Screen Reader Testing

- Open NVDA (Windows) or VoiceOver (Mac)
- Navigate via heading structure — does it make sense?
- Listen to image alt text — is it descriptive?
- Are form labels announced correctly?
- Are error messages announced?
- Do dynamic content changes get announced?

Visual Testing

- Zoom to 200% — is content still usable?
- Check color contrast with a tool (WebAIM contrast checker)
- Disable images — is all content still understandable?
- Test in high contrast mode
- Ensure no information is conveyed only through color

Motion and Timing

- Reduce motion in system preferences — do animations stop?
- Can you extend time limits on forms?
- Does autoplay video have a pause button?

Integrating a11y into CI

# .github/workflows/a11y.yml
name: Accessibility Tests
on: [pull_request]

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run build
      - run: npx playwright install --with-deps
      - run: npx playwright test --grep @a11y
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: a11y-report
          path: a11y-report/

Best Practices

1. Shift Left

Run a11y tests early in development, not just before release. Catch issues when they're cheapest to fix.

2. Combine Automated + Manual

Automated tools catch 30% of issues. Manual testing catches the rest. Both are required.

3. Use Semantic HTML

Proper heading hierarchy, landmark elements (<nav>, <main>, <footer>), and form labels prevent most common violations.

4. Test with Real Assistive Technology

Run through key flows with a screen reader at least once per sprint.

5. Set Accessibility Budgets

Block PRs that introduce new violations. Use a threshold (e.g., zero violations for critical pages).

Common Mistakes

1. Relying Only on Automated Tools

Automated tools miss contextual issues — unclear alt text, poor reading order, confusing navigation.

2. Ignoring Keyboard Navigation

"If it works with a mouse, it works" — no. Many users rely entirely on keyboard navigation.

3. Adding ARIA Instead of Using Semantic HTML

ARIA doesn't fix bad HTML. Start with proper semantic elements; add ARIA only when needed.

4. Insufficient Color Contrast

Light gray on white text is common and fails WCAG AA. Use contrast checkers.

5. Not Testing Dynamic Content

Single-page apps that update content without page reloads may not announce changes to screen readers.

6. Missing Form Error Associations

Error messages must be programmatically associated with form fields using aria-describedby.

7. Forgetting Focus Management

When a modal opens, focus should move into it. When it closes, focus should return to the trigger.

Practice Questions

1. What does WCAG stand for? Web Content Accessibility Guidelines — the international standard for web accessibility.

2. What percentage of a11y issues do automated tools catch? Approximately 30%. The remaining 70% require manual testing.

3. What is the most common WCAG AA violation? Insufficient color contrast between text and background.

4. How do you test keyboard navigation? Tab through all interactive elements, check focus visibility, ensure logical order, and verify all actions work without a mouse.

5. Challenge: Audit a page and create a remediation plan. Run axe-core on a page, list all violations by severity, and create a prioritized list of fixes.

Mini Project: Accessibility Audit Script

// a11y-audit.js
const AxeBuilder = require('@axe-core/playwright');
const { chromium } = require('playwright');

async function auditAccessibility(url) {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto(url);

  const results = await new AxeBuilder({ page }).analyze();

  console.log(`Accessibility audit for: ${url}`);
  console.log(`Violations found: ${results.violations.length}`);
  console.log(`Passes: ${results.passes.length}`);

  results.violations.forEach(violation => {
    console.log(`\nāŒ ${violation.id} (${violation.impact})`);
    console.log(`   ${violation.description}`);
    console.log(`   Elements affected: ${violation.nodes.length}`);
    console.log(`   Help: ${violation.helpUrl}`);
  });

  await browser.close();
  return results;
}

auditAccessibility('https://example.com');

FAQ

What is accessibility testing?

The process of verifying that web applications are usable by people with disabilities, including screen reader users, keyboard-only users, and users with visual or motor impairments.

What tools can I use for automated a11y testing?

axe-core (Playwright/Cypress integration), Lighthouse, WAVE, and Pa11y. axe-core is the most widely used engine.

What is WCAG AA compliance?

The most common accessibility standard, required by many legal frameworks. It covers sufficient color contrast, keyboard navigation, screen reader support, and more.

Can automated testing replace manual a11y testing?

No. Automated tools catch ~30% of issues. Manual testing with screen readers and keyboard navigation is essential.

How do I integrate a11y tests into CI?

Use Playwright with axe-core or Cypress with cypress-axe. Run as part of your test suite and fail builds on new violations

What's Next

Testing React Apps — React Testing Library & Vitest
CI/CD Testing Pipeline — Automating Tests in CI
E2E Testing Guide

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro