Accessibility testing sounds like it needs a specialist. Some of it does. But a large share of the problems on a typical site are things any tester can find in an afternoon, and a meaningful chunk can be caught automatically on every pull request.

Start with the automated third

The honest framing first: automated tools find roughly a third of accessibility issues. That's not a reason to skip them, it's a reason not to stop there. A third, for free, forever, is a good deal.

axe-core plugs into most test runners. With Playwright:

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

test('checkout page has no obvious accessibility violations', async ({ page }) => {
  await page.goto('/checkout');

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

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

When you add this to an existing project, expect a large number of failures on day one. Don't try to fix them all before merging. Snapshot the current violations, fail the build only on new ones, and burn down the backlog separately.

What this catches reliably: missing alternative text, form inputs with no label, insufficient colour contrast, invalid ARIA attributes, duplicate element IDs, missing page language.

The manual checks worth doing every time

These take about ten minutes per page and find the things tools can't.

Unplug the mouse. Tab through the whole page. Can you reach every interactive element? Can you see where the focus is at all times? Can you close a modal without a mouse, and does focus return to where it was? Keyboard traps in modals and custom dropdowns are extremely common and never show up in automated scans.

Zoom to 200%. Text should reflow, not get cut off or overlap. Check on a narrow window too, since responsive breakpoints and zoom interact in unexpected ways.

Read the page with a screen reader. VoiceOver on macOS is built in (Cmd+F5) and NVDA is free on Windows. You don't need to be fluent. Just navigate the headings and listen to whether the page makes sense as a sequence of announcements. Buttons that announce as "button" with no name, images described as "image", and headings that skip from h1 to h4 all become obvious immediately.

Check that the alternative text says something useful. A tool can tell you alt is present. Only a human can tell you alt="image1.png" is worthless, or that a decorative divider should have alt="" instead of a description.

Turn off CSS. The reading order of the raw HTML should still be sensible. If it isn't, the visual order and the DOM order have diverged, and keyboard and screen reader users get a different page than everyone else.

Where to put it in your process

I treat accessibility like any other quality attribute: a small automated gate on every pull request, a manual pass on anything new or substantially redesigned, and a deeper audit on the core user journeys once or twice a year.

How to report it

Accessibility bugs get deprioritised when they're reported as abstractions. "Fails WCAG 1.3.1" means nothing to most developers. Write what a person can't do instead:

A keyboard user cannot complete checkout. After opening the delivery address modal, Tab cycles through the page behind the modal instead of its fields, and Escape does not close it. The only way out is to reload the page.

That version gets fixed.