An automated WCAG scan is the start of an audit, not the end

The most common misconception I run into with accessibility goes like this: “We ran the scanner, it found zero errors, so we’re WCAG compliant.” That’s like declaring your app bug-free because it passed the linter.

What automated tools check well

Scanners like axe-core are fast, repeatable and merciless with any error that can be described as a rule. Among other things, they’ll catch:

• a missing alt attribute on an image
• form fields without a label
• insufficient contrast between text and background
• incorrect use of ARIA attributes
• a missing lang attribute on the document

These are important errors, and they’re worth catching automatically, ideally in CI, on every change.

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

test('home page has no detectable WCAG violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'])
    .analyze();

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

What automated tools won’t check

A scanner knows that an image has an alt. It doesn’t know whether alt="image" says anything. It knows that a button has a name. It doesn’t know whether clicking it sends focus jumping back to the top of the page. These are a few of the criteria where I always need a human:

• Focus order and keyboard traps in modals, menus and custom components.
• Whether alt text, headings and links make sense. Five “Read more” links side by side will pass the scanner without a word.
• Focus Not Obscured (2.4.11, new in WCAG 2.2): a sticky header can cover the very element you’re on.
• Reflow at 320 px and zoom to 200%. A scanner won’t see that text is overlapping.
• Clear error messages. “Invalid value” is a message, but it isn’t help.

What my process looks like

I split an audit into six steps. The automated scan is the first of them, not the only one.

1. Automated scan as triage: it quickly shows the scale of the problem and the recurring errors in templates.
2. Keyboard walkthrough of the key paths: navigation, forms, checkout, login.
3. Screen readers: NVDA with Firefox on Windows, VoiceOver with Safari on macOS and iOS.
4. Zoom and reflow: 200%, 400%, 320 px width, landscape orientation.
5. Content review: alt text, heading structure, link text, video captions.
6. Report: every issue with its WCAG success criterion, steps to reproduce, impact on users and a suggested fix.

Where automation stays for good

The point isn’t to give up on automated tools. After the audit and the fixes, a test in CI makes sure the same errors don’t come back with the next deploy. I repeat the manual audit when the interface changes significantly, not on every code change.

We use the same split in DockAccess: automated scanning and monitoring run continuously, and an expert audit covers what automation can’t see.

Where to start tomorrow

If you have half an hour, put the mouse aside and try to get through the most important path on your site using only the keyboard. Note every place where you can’t tell where focus is, or can’t activate something. That will be a better start to an audit than the best automated report.