Accessibility Checks and Axe Integration

Accessibility is essential for inclusive products and often a regulatory requirement. While manual audits remain important, you can catch many common issues automatically by integrating accessibility checkers like axe with Playwright.

Running Axe Accessibility Checks in Playwright #

You can use libraries such as @axe-core/playwright or inject axe into the page to scan for violations after navigation or key interactions.

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

test('homepage has no serious a11y violations', async ({ page }) => {
  await page.goto('https://demo.myshop.com');
  const results = await axe.run(page, {
    runOnly: ['wcag2a', 'wcag2aa'],
  });

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

Combining accessibility assertions with your functional tests ensures that regressions are caught early, before features ship.

Common Mistakes #

Mistake 1 — Running a11y scans only once, manually #

This misses regressions.

❌ Wrong: Doing a single audit before release and never automating it.

✅ Correct: Integrate scans into CI so new issues are caught on every change.

Mistake 2 — Ignoring keyboard and focus behaviour #

This leaves important gaps.

❌ Wrong: Only checking contrast and labels but not tab order or focus visibility.

✅ Correct: Add manual checks or automated flows that exercise keyboard navigation.