A practical WCAG 2.2 audit methodology that survives engineering review

Most accessibility audits I review have the same structural problem: they read like a list of grievances rather than a map for action. The standard is referenced, the violations are flagged, but engineering can't tell what to fix first, what's actually broken versus a false positive, or what 'done' looks like for any given finding. This is the methodology I use to avoid that — refined across 30+ audits in production environments.

1. Scope before tooling

An audit's value is determined before the first scan runs. I start every engagement with a scoping document that pins down: which user journeys are in scope (not which pages — journeys cross pages), which assistive technology targets matter, which conformance level is the goal (WCAG 2.2 AA is the default), and what 'fixed' means contractually. This document is the source of truth when a finding is contested later.

2. Manual-first, automated-second

Automated tools catch maybe 30% of WCAG issues. They're useful as a sweep, not as a foundation. I run the manual pass first — keyboard-only traversal, screen reader (NVDA + VoiceOver minimum), and a contrast and zoom check — then layer axe-core and Pa11y output on top to catch what I missed. Reversing this order makes auditors over-index on automated noise and miss the issues that actually block users.

3. Severity as a model, not a guess

Severity has to be defensible. I score every finding on three axes: user impact (can the user complete the journey at all?), frequency (how many pages or components are affected?), and assistive-tech dependency (does the issue affect AT users disproportionately?). Critical = blocks completion for AT users; High = severe friction or partial blocking; Medium = inconsistent experience; Low = polish. Severity is what engineering uses to prioritize, so the rubric has to be transparent.

4. Findings need reproduction steps, not just rule numbers

Every finding in my reports includes: the WCAG success criterion, the user journey it appears in, exact reproduction steps including AT setup, observed behavior, expected behavior, and recommended remediation direction (not full code, but enough that an engineer knows where to look). This is the difference between an audit a team uses and one that sits in a Drive folder.

5. The roadmap is the deliverable

Findings are inputs. The deliverable is the roadmap: grouped by component (so a single fix knocks out N findings), sequenced by severity and effort, and sized to sprint cadence. I include a 'quick wins' section — fixes under 2 hours each — because closing the easy ones first builds momentum and de-risks the engagement.

Common failure modes

• Auditing pages instead of journeys — misses cross-page state issues like focus loss after navigation.
• Using only Chrome + NVDA — Safari + VoiceOver behaves differently and is required for fair coverage.
• Logging every automated false positive — credibility erodes fast when 20% of the report is wrong.
• No reproduction steps — engineering can't act on findings they can't replicate.
• Treating WCAG 2.2 as a checklist — the standard is a floor, not a ceiling. Audit for usability too.

What this looks like in practice

On a recent audit of a multi-tenant SaaS dashboard, this methodology surfaced 47 unique findings across 8 components. The roadmap grouped them into 12 component-level remediation tickets, of which 4 were marked as quick wins. The team shipped the quick wins in their next sprint, closed 60% of findings within 6 weeks, and used the methodology document itself as part of their ongoing accessibility review process. That second outcome — the methodology outliving the engagement — is the real measure of an audit that worked.