How to Run a Website Accessibility Audit

Most accessibility audits start and end with an automated scan, a PDF of results, and a false sense of completion. Automated tools reliably detect only a minority of WCAG success criteria — the widely cited figure is roughly a third, and the rest require human judgment.

That is not an argument against scanners. They are fast, free, repeatable, and excellent at what they do. It is an argument for knowing which third you just tested.

What automated tools genuinely catch

Scanners are good at machine-checkable, binary conditions:

• Missing alt attributes
• Insufficient color contrast ratios
• Missing form labels
• Empty links and buttons
• Missing page language attribute
• Some heading-structure problems
• Missing table headers

If a scan reports these, they are almost certainly real. Automated findings have very few false positives. Fix them first — they are cheap and unambiguous.

What they cannot catch

Everything requiring judgment about meaning:

• Whether alt text is useful. A scanner confirms alt exists. It cannot tell that alt="image1.jpg" is worthless. See writing alt text that actually works.
• Whether reading order makes sense. The DOM order may be valid and still nonsensical.
• Whether keyboard navigation works. Focus traps, invisible focus, illogical tab order.
• Whether headings describe their sections, rather than merely existing at the right level.
• Whether error messages are helpful and programmatically associated with their field.
• Whether a custom widget behaves as its ARIA role promises.
• Whether captions are accurate. A scanner sees a caption track exists, not that it says the right words.
• Whether color is the only means of conveying something.

The gap is not marginal. A site can pass a clean automated scan and be genuinely unusable with a screen reader.

A five-layer audit that produces real evidence

1. Automated scan across a representative sample

Use more than one tool — axe DevTools, WAVE, Lighthouse, Pa11y all differ in coverage. Do not scan only the homepage. Sample by template: homepage, landing page, article, search results, form, results table, login, error state, PDF viewer. Ten well-chosen pages beat a thousand of the same template.

2. Keyboard-only pass

Put the mouse away. Tab through each sampled page and confirm:

• Every interactive element is reachable.
• Focus is always visible — and not hidden behind a sticky header (a WCAG 2.2 criterion).
• Tab order follows visual order.
• You can escape every modal, menu, and widget.
• No focus traps — anywhere you can tab into, you can tab out of.
• Skip links work.

This single pass finds more real problems per hour than any other technique, and it needs no special software.

3. Screen reader pass

Test with at least one real screen reader — NVDA (free, Windows), JAWS, or VoiceOver (built into macOS and iOS). You do not need expertise to find serious problems; you need to attempt real tasks.

Try to: find a specific piece of information using headings; complete a form and recover from a deliberate error; understand what a chart is telling you; work out what each unlabeled icon button does.

4. Zoom, reflow, and responsive

Set browser zoom to 200% and then 400%, and check content reflows without horizontal scrolling or overlap. Test with a small viewport. This catches fixed-width layouts and absolutely positioned elements that collapse under magnification.

5. Documents and media

Almost always the largest omission. Your PDFs, Office files, and video are in scope. A conformant website that links to hundreds of untagged PDFs has an accessibility problem measured in thousands of pages. See our PDF remediation guide, making Office files accessible, and accessible video.

Recording findings so they hold up

An audit is only as useful as its record. For each finding, capture:

• Which success criterion it fails, by number — “3.3.2 Labels or Instructions,” not “form problem.”
• Where — URL and element.
• User impact — who is blocked, and from what. This drives prioritization far better than severity labels.
• How to reproduce it.
• How it was found — automated, keyboard, screen reader.

Then date it and keep it. A dated audit trail showing issues found and closed is the single most valuable document you can produce if your conformance is ever questioned. “We fixed it” carries far less weight than “found 2026-08-28, closed 2026-09-14.”

That record is also what makes a conformance report defensible — see what is a VPAT.

Prioritizing what you found

Not by severity label. By blocking impact times reach:

1. Blockers on critical paths — anything preventing completion of a task with no alternative. An inaccessible benefits application outranks everything.
2. Blockers on high-traffic pages.
3. Site-wide template issues — one fix, hundreds of pages.
4. Everything else, worked steadily.

A template-level fix is almost always the best return available: correcting a header component fixes every page at once.

How often

• Automated scans: continuously, in your build pipeline, so regressions surface immediately.
• Keyboard and screen reader passes: on every significant release, and on any new template.
• Full audit: annually, and whenever you redesign.

Accessibility is not a project that completes. Sites that stay conformant treat it as part of shipping — which is far cheaper than the alternative of remediating everything again in two years.

Getting help

Taika provides accessibility assessments, ADA website accessibility, Section 508 remediation, and PDF & document accessibility. We also offer a free PDF accessibility checker for a quick read on a single document.

For an independent audit with findings mapped to specific success criteria, request an assessment.