The accessibility audit process from initiation to delivery.

Phases

A complete audit moves through six phases. Skipping any of them weakens the result.

1. Define scope

Decide what is in and out of the audit. Includes:

• Which service or sub-product
• Which user types and journeys
• Which referential (guideline) and conformance level
• Time boundary (the audit is a snapshot of one moment)

Document scope in the audit description and revisit if the product changes during the audit.

2. Select samples

Pick the pages or screens that represent the service. See sampling.

3. Map journeys (when applicable)

Identify the most important user tasks and trace them across samples. Journey mapping can be across samples, but also across multiple audits. See journey mapping.

4. Evaluate criteria

For each (sample, criterion) pair:

1. decide a verdict
2. record the findings (the problems) following finding quality methodology,
3. record the proposed solutions,
4. annotate with notes (see using notes)
5. add images for evidence

5. Build the accessibility statement

Aggregate failures into a coherent declaration. This statement will be composed with dedicated types of notes named "notes for statement". See statement quality.

6. Deliver the report

Produce the final report for the audit commissioner. The report is technical and can be a summary or extract of the audit findings; the statement is public-facing and should inform potential disabled users about accessibility issues.

Common process mistakes

• Skipping scope definition and sampling, then drifting through whatever the auditor finds.
• Recording verdicts without problem and solution text, leaving findings unactionable.
• Auditing the page-set without identifying journeys, missing cross-page or touch point failures. (e.g an e-mail notification redirecting to a non-audited page)
• Treating "Not tested" as a final verdict rather than a temporary state.
• Writing a defensive statement instead of an honest one.

Time and effort

Auditing one sample against the AA level of WCAG 2.2, RAWeb 1.1, or RGAA 4.1.2, takes a trained auditor roughly 1 to 3 hours depending on page complexity. Per-sample time decreases on larger audits because page templates repeat and the propagate status feature helps. Plan accordingly.