Add accessibility testing to your process

How to fix

1. 1 Add an automated a11y check (e.g. axe) to CI.
2. 2 Do a keyboard-and-screen-reader pass on key flows before each release.

Fix it in your stack

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('home page has no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

Common mistakes

• • Relying on an automated scan alone, which finds only part of the barriers.
• • Testing once before launch and never again, so every later component goes unchecked.
• • Running the check but not failing the build on new violations, so the results are ignored.

How to verify

1. 1 Confirm an automated accessibility check runs on every pull request and fails it on new violations.
2. 2 Confirm the release checklist includes a keyboard-only and screen reader pass over the key flows.
3. 3 Introduce a deliberate violation on a branch (an image without alt) and confirm the check flags it.

Questions

Is an automated check enough?

No. Tools find the mechanical barriers such as missing labels, alt text and low contrast. A keyboard-only pass and a screen reader pass over the key flows find the rest, such as a focus trap or a confusing reading order.

Where should accessibility tests run?

In CI on every pull request, so a new component cannot merge with a violation, plus a manual pass before each release.

Why does my report list this step?

A website scan cannot see this from outside. The step appears when you answer No to the question a scan asks about accessibility testing, and it leaves your plan once you answer Yes on a later scan.