Webscan Documentation

Lesson 14 · Manual audits

Phase 3 · Beyond the public page — Lesson 14 of 21 · All lessons

Objective: understand what a manual audit is and why it matters, run one against WCAG checkpoints, record outcomes with evidence, and turn failures into issues.

Before you start: a website (Lesson 3). This lesson is hands-on human testing — no scan required.

Why manual audits exist

Automated scans are fast, but they can only catch what a machine can measure — research suggests automated tools find roughly a third of accessibility issues. The rest need human judgement: Does the keyboard focus order make sense? Does this image's alt text actually describe it? Can a screen-reader user complete the task?

Manual audit — a structured, human-run review of a website against a checklist of accessibility checkpoints, where a person tests each one and records the result. It's how you cover the barriers automation can't see, and how a serious accessibility assessment is actually done.

Key terms

• Checkpoint — one specific thing to test, tied to a WCAG success criterion. Each checkpoint has a title, a category, its WCAG criterion and level (A or AA — A is the most basic requirements, AA the standard most organisations target), and instructions telling the tester how to check it.
• WCAG — the Web Content Accessibility Guidelines, the international standard for accessibility (first met in Lesson 5). Checkpoints map your testing directly onto it.
• Outcome — your recorded result for a checkpoint (pass, fail, and so on).
• Scope — a note on what this audit covers (which pages, which flows), so the audit's boundaries are explicit.

Create an audit

1. From the website page, open Manual audit and create one with a title (e.g. "Homepage & checkout — WCAG 2.2 AA") and a scope describing what you're assessing.
2. Webscan populates the audit with the active checkpoints, grouped by category ("Checkpoint group"). Each starts at the outcome Not tested.

An audit has a status of its own — Draft, In progress, or Completed — and shows audit progress (the percentage of checkpoints you've answered), so you can see how far along you are.

Work through the checkpoints

For each checkpoint, read its instructions, test the site by hand, and record what you found. For every one you set:

• Outcome — one of:

• Audit notes — what you observed and how you tested it.
• Evidence URL — an optional link to a screenshot, recording, or page that documents the result (use Open evidence to revisit it later).

Choose Save checkpoint to record each result. Work down the list until progress reaches the coverage you need.

Finish and act on it

When you've tested everything in scope, choose Mark audit complete. This stamps the audit as finished and dated — your defensible record that a human assessed the site against WCAG on that day.

Crucially, a Fail doesn't just sit in the audit. Just as a scan finding can become an issue, an audit result can be turned into a remediation issue — so the barriers your human testing found flow into the same tracking, fixing, and retest workflow you learned in Phase 2. Manual and automated findings converge into one backlog.

How manual audits fit with scanning

Think of your coverage as two halves that meet:

• Automated scans / journeys / exploration — fast, wide, machine-measurable barriers.
• Manual audits — the human-judgement barriers automation misses.

A thorough assessment uses both, and both end up as issues on the same board. That convergence is the whole point: one place to see, prioritise, fix, and verify every barrier, however it was found.

Tips & pitfalls

• Write a real scope. "Homepage, product page, and checkout, WCAG 2.2 AA" makes the audit meaningful and its boundaries honest.
• Record evidence as you go. A link to a screen recording of the failure is worth far more later than a note written from memory.
• "Not applicable" is a valid, useful answer — but say why in the notes, so the record holds up.
• Turn Fails into issues immediately, while the context is fresh, rather than re-deriving them after the audit.

Recap

• A manual audit is human testing against WCAG checkpoints — covering the ~two-thirds of barriers automation can't detect.
• Each checkpoint gets an outcome (Pass / Fail / Not applicable / Needs review / Not tested), notes, and optional evidence.
• Track progress, then Mark audit complete for a dated, defensible record.
• Fails become issues, converging with automated findings into one backlog.

Try it yourself

Create a manual audit for your homepage with a clear scope. Work through five checkpoints — actually test each on the page — recording an outcome and a note for every one. Turn any Fail into a remediation issue, then mark the audit complete.

Previous: ← Lesson 13 · User journeys Next: Lesson 15 · Recorded audit sessions →