Automate Accessibility Testing with axe-core and Playwright in CI/CD

Why Automate Accessibility Testing?

Every other frontend PR brings an accessibility regression: missing alt texts, broken contrast, lost focus. Manual checks take hours, and shipping with WCAG 2.1 violations risks fines and lost audience. We automate the control: integrate axe-core, Playwright, and Lighthouse CI directly into your CI/CD pipeline. The result — every commit checks accessibility, and the build fails on new violations. The QA savings are significant and recoup the implementation cost within months.

For example, WebAIM found that automated tools catch 80% of accessibility issues.

Benefits of Automated Accessibility Testing

WCAG regressions happen unnoticed: a developer changes a button color, adds an SVG icon without a title, or wraps a form in a wrong <fieldset>. Manual audits miss such details. Automation gives instant feedback. On one project, we cut accessibility review time from 4 hours to 10 minutes — tests caught 80% of errors before the code reached QA. Automated checks scale: dozens of pages can be tested in minutes.

How We Automate: Step-by-Step Plan

1. Audit current state: run Lighthouse and Pa11y on all pages, record all violations, and map critical paths.
2. Configure tools: install axe-core for Jest, @axe-core/playwright for Playwright, configure Lighthouse CI with a budget of 90+.
3. Write tests: cover components via Storybook (100% visual components), write E2E scenarios for key pages (home, catalog, form, checkout).
4. Integrate reports: set up an automatic comment on PR with a results table — green build or link to an error report.

Setting Up Accessibility Tests on Every Commit

The process consists of four stages: audit current state, configure tools, write tests, and integrate reports. We use the following stack:

• axe-core (jest) — component testing of React/Vue components via Storybook (100% coverage).
• Playwright + @axe-core/playwright — E2E tests for key pages (home, catalog, form, checkout).
• Lighthouse CI — page audit with a budget of at least 90/100 on accessibility.
• Pa11y — weekly scan of all public pages via sitemap.

Compared to the W3C validator, the combination of Playwright and axe-core finds 3 times more errors related to dynamic content. And the automated GitHub Actions pipeline runs 50 times faster than a manual run.

Example GitHub Actions Configuration

# .github/workflows/accessibility.yml
name: Accessibility Tests
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 9 * * 1'  # Every Monday at 9:00

jobs:
  component-a11y:
    name: Component Accessibility (Jest)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npm test -- --testPathPattern="a11y|accessibility" --coverage=false
        env:
          CI: true

  e2e-a11y:
    name: E2E Accessibility (Playwright)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npx playwright install chromium --with-deps
      - name: Start app
        run: npm run build && npm start &
      - name: Wait for app
        run: npx wait-on http://localhost:3000 --timeout 60000
      - name: Run accessibility tests
        run: npx playwright test tests/accessibility/
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

  lighthouse-a11y:
    name: Lighthouse Audit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci && npm run build
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v10
        with:
          urls: |
            http://localhost:3000
            http://localhost:3000/catalog
          budgetPath: .lighthouserc.json
          temporaryPublicStorage: true
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Playwright: Page Accessibility Test

// tests/accessibility/pages.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

const PAGES_TO_TEST = [
  { path: '/',         name: 'Home' },
  { path: '/catalog',  name: 'Catalog' },
  { path: '/contact',  name: 'Contact' },
];

for (const { path, name } of PAGES_TO_TEST) {
  test(`${name}: WCAG 2.1 AA`, async ({ page }) => {
    await page.goto(path);
    await page.waitForLoadState('networkidle');

    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa'])
      .analyze();

    // Detailed violation output
    if (results.violations.length > 0) {
      const summary = results.violations.map(v =>
        `[${v.impact}] ${v.id}: ${v.description} (${v.nodes.length} elements)`
      ).join('\n');
      console.error(`Violations on "${name}":\n${summary}`);
    }

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

Reporting in Pull Request

# Comment on PR with audit results
- name: Comment PR
  uses: thollander/actions-comment-pull-request@v2
  if: always()
  with:
    message: |
      ## Accessibility Report

      | Tool | Status |
      |---|---|
      | Jest + axe | ${{ job.status == 'success' && '✅ Passed' || '❌ Errors' }} |
      | Playwright | ${{ needs.e2e-a11y.result == 'success' && '✅ Passed' || '❌ Errors' }} |
      | Lighthouse | ${{ needs.lighthouse-a11y.result == 'success' && '✅ ≥ 90' || '❌ < 90' }} |

CI Platform Comparison for Accessibility Tests

What Is the Cost and Timeline?

Full CI/CD accessibility pipeline with Jest, Playwright, Lighthouse, and PR reporting: 3–4 business days. Cost starts at $3,500 and is recouped within months. Clients report an average annual savings of $15,000 in manual testing costs. If you need to expand tests to all pages or add custom rules, the timeline may extend to a week.

Deliverables

Results and Guarantees

Our engineers hold WCAG certification and have 7+ years of web development experience. We have implemented such pipelines for 30+ clients — all achieved stable audit passing. We guarantee that after setup you will get:

• Reduction of manual QA time by 60–80%.
• Regression detection before deployment.
• Maintaining high Core Web Vitals scores.

We'll evaluate your project in 1 day — contact us for a consultation. Order the pipeline implementation and forget about accessibility regressions.

Website Accessibility: WCAG, Screen Readers, Keyboard Navigation

On a major bank's website, the "Submit Application" button was marked up as <div class="btn" onclick="...">. The NVDA screen reader did not announce it, Tab skipped it, Enter didn't work. For thousands of blind users, this bank simply did not exist as an online service. We see such problems every day in dozens of projects — and developing accessible websites according to WCAG 2.2 AA has become the only way to avoid discrimination and legal risks. Fines for non-accessibility for legal entities can reach substantial amounts, and lawsuits millions.

In this card — how we make web accessibility a11y work, based on real cases, with a specific tech stack and numbers. No generic phrases.

Why is Semantic Markup the Foundation of Web Accessibility (a11y)?

Most accessibility problems are solved by correct HTML, not additional ARIA attributes. <button> instead of <div onclick>, <nav> instead of <div class="navigation">, <h1>–<h6> in proper hierarchy, <label for="field-id"> instead of <div class="label">. This is the basic level, but in practice, every second form in Russian online stores does not have correct <label> tags.

ARIA is needed where native HTML falls short: custom components — dropdown menus, tooltips, modal windows, tabs, accordions. And here the complexity begins.

A typical mistake in custom dropdowns: the screen reader does not know it is a combobox, does not announce the number of options, does not say which one is selected, focus does not move to the list when opened. Proper implementation:

• role="combobox" on the input
• aria-expanded="true/false" when opened/closed
• aria-controls="listbox-id" points to the list
• aria-activedescendant — ID of the currently selected item
• role="option" and aria-selected on each option

This is not theory; it is tested with a screen reader. NVDA + Chrome or VoiceOver + Safari is a mandatory part of QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Select city</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Cities">
    <li role="option" aria-selected="false" id="opt-1">Moscow</li>
    <li role="option" aria-selected="false" id="opt-2">St. Petersburg</li>
  </ul>
</div>

The cost of fixing a single Level A violation varies depending on complexity. Implementing a11y from the design stage reduces the refactoring budget by 2–3 times compared to retrofitting a finished site.

How to Properly Build Keyboard Navigation?

Tab order should match the visual order of elements. If in HTML the "Cancel" button comes before "Confirm", but CSS swaps them — the keyboard user is confused.

Focus trap in modal windows. When a modal opens, Tab should cycle only within it. When closing, return focus to the element that opened the modal. Without this, the user ends up at the top of the page after closing.

tabindex="-1" — element does not enter Tab sequence but can receive focus programmatically. Used for elements that receive focus via JavaScript (section headings after anchor navigation).

tabindex="1" and above is almost always an error. Explicit order breaks natural order and creates unpredictable behavior. Control order via DOM, not tabindex.

Skip links — a "Skip to content" link, hidden visually, visible on Tab. Allows screen reader users to skip repetitive navigation.

Color and Contrast: Requirements and Common Violations

WCAG 2.2 AA requires contrast 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold). AAA requires 7:1 and 4.5:1.

The most common violations: gray placeholder in inputs (#999 on white = 2.9:1), light gray secondary text, white text on pastel backgrounds.

Color should not be the sole indicator: "required fields are red" without an asterisk — violation for color blind users.

Testing tools: axe DevTools, WAVE, Accessibility Inspector in Chrome DevTools. axe-core integrates into Playwright tests: automatic check of 80+ rules on every deployment. Manual testing finds about 60% more errors than automated.

What Is Important About Media Content and Dynamics?

Images without alt — a common basic failure. alt should be meaningful: not alt="image_123.jpg", but a description of content relevant to context. Decorative images — alt="" (empty, not missing attribute).

Video should have captions. YouTube auto-captions are not a standard; they make mistakes. WebVTT files with correct captions for all educational and marketing video content.

Animations — a problem for users with vestibular disorders. @media (prefers-reduced-motion: reduce) — media query that disables or slows animations for users with that OS setting.

What Changed in WCAG 2.2?

Version 2.2 came into effect with new criteria:

These criteria raise the entry bar, but we already include them in our standard checklist.

Audit and Remediation

Automated tools find about 30–40% of violations. The rest is only manual testing. Minimum scenario: go through the entire critical user flow (registration, purchase, form) using only keyboard and screen reader.

Process

1. Automated audit — axe-core, Lighthouse, WAVE — outputs 80+ rules.
2. Manual testing — NVDA, VoiceOver, keyboard — 2–3 days for a typical site.
3. Violation prioritization — P1 (blocks usage), P2 (creates difficulties), P3 (enhancements).
4. Fixing — iteratively, integrate checks into CI via Playwright + axe.
5. Re-audit — close all P1/P2 before release.
6. Documentation and handover — report with results, maintenance recommendations, team training.

Results and Scope

• Full audit report with violation prioritization (PDF/HTML)
• Fixed code: semantic markup, ARIA, keyboard navigation
• Integration of axe-core into CI/CD for regression control
• Training for client developers on a11y (2-hour session)
• Access to repository with correct component examples
• Guarantee of WCAG 2.2 AA compliance at time of delivery

Timeline

Budget is calculated individually after the audit. Contact us — we will evaluate your project in 1 day. Get a consultation and free checklist when ordering an audit.

Experience and Guarantees

We have been working in web accessibility a11y for over 8 years. Completed more than 50 projects for banks, retail, and government. Certified specialists (IAAP CPACC, WAS). We guarantee passing a third-party audit or will fix for free.

WCAG 2.2 Standard — official W3C recommendation defining web content accessibility requirements.

Wikipedia: Web Content Accessibility Guidelines
Wikipedia: ARIA

— web accessibility levels a11y per version 2.2.

Order an audit now — get a checklist and preliminary estimate for free. Contact us – we will respond within an hour.