Tracking accessibility coverage across an audit means knowing exactly which pages, components, and WCAG success criteria were evaluated, which were not, and where issues live within that map. Coverage is the audit's accountability layer. Without it, an audit report is a list of issues with no context. With it, the report becomes a working document your team can act on and update.
Coverage tracking starts before the audit, continues through evaluation, and remains active during remediation. The same map that defines scope becomes the structure for issue tracking, validation, and reporting. When done well, coverage answers a single question at any moment: what has been reviewed against what standard, and what is left.
| Coverage Layer | What It Captures |
|---|---|
| Scope | Pages, templates, components, and user flows included in the audit |
| Standard | WCAG version and conformance level (2.1 AA or 2.2 AA) |
| Criteria Map | Each success criterion evaluated against each in-scope asset |
| Issue Log | Identified issues tied to specific criteria, locations, and severity |
| Status | Open, in remediation, validated, or closed for each issue |
Start with a Defined Scope
Coverage begins with scope. Before a single page is evaluated, the audit needs a documented list of what is in and what is out. For a website, that usually means a representative sample of templates, key user flows, and unique components. For a web app or mobile app, it covers core screens and the interactions a user actually completes.
Write scope down. A scope document that lists URLs, screen names, and components is the spine of coverage tracking. Every issue identified later ties back to a row in that document.
Map Each WCAG Success Criterion to Each Asset
Coverage is two-dimensional. One axis is the in-scope asset list. The other is the WCAG success criteria at the chosen level. A manual audit evaluates each criterion against each asset, which is why scans only flag approximately 25% of issues. The other 75% require human evaluation against the criteria map.
For a WCAG 2.1 AA audit, the criteria set is fixed. Your tracking system should mark each criterion as evaluated, not applicable, or issue identified for every asset in scope. That grid is the coverage record.
What Should the Issue Log Capture?
An issue log without context is hard to act on. Each entry should tie back to the criterion that was not met, the specific asset where it appears, the severity, and enough detail for a developer to reproduce and fix it. That structure also makes validation possible later, because the same fields drive the recheck.
Useful fields for each issue include:
WCAG criterion: The specific success criterion not met
Location: URL, screen name, or component identifier
Description: What the issue is and how it presents
Severity: Based on user impact and risk
Recommendation: Guidance for remediation
Status: Open, in progress, validated, closed
Prioritize Without Losing the Coverage Picture
Prioritization is necessary, but it should not pull issues out of the coverage record. Risk Factor or User Impact prioritization formulas help order remediation work without removing items from the log. An issue marked low severity is still tracked, still tied to its criterion, and still part of the conformance picture.
The mistake is treating prioritization as filtering. Coverage tracking shows everything. Prioritization shows what to fix first.
Keep Tracking Active During Remediation
Coverage tracking does not end when the audit report is delivered. As fixes are made, status updates flow back into the same log. Validation confirms each fix against the original criterion and location. Closed issues stay in the record as historical context.
This is where a dedicated platform pays off. Spreadsheets work for small projects, but as issue counts grow and teams expand, the Accessibility Tracker Platform provides a structured way to manage the same coverage map across audits, remediation, and revalidation. The platform keeps scope, criteria, issues, and status in one place so the coverage view is always current.
How Often Should Coverage Be Refreshed?
Coverage is a snapshot of one audit at one point in time. Sites and apps change. New templates, new components, and new flows expand scope. A coverage record that was complete six months ago may now miss pages that have been added since.
Plan for periodic recoverage. After significant releases, expand the scope document, re-evaluate against the criteria, and update the issue log. Combined with ongoing monitoring scans for regression detection, the coverage record stays accurate over time.
Frequently Asked Questions
Do I need a platform to track audit coverage, or can a spreadsheet work?
A spreadsheet can work for a small site with a single audit. As scope grows, teams expand, and remediation cycles repeat, a structured platform keeps the coverage map intact. The Accessibility Tracker Platform is built around this workflow.
What does it mean to mark a criterion as not applicable?
Some success criteria do not apply to certain assets. For example, a criterion related to video captions does not apply to a page with no video. Marking it not applicable in the coverage record shows the criterion was considered, not skipped.
Should automated scan results be included in the coverage record?
Scans and audits are separate activities. Scan results can supplement monitoring between audits, but they do not contribute to coverage against WCAG. Only the manual audit determines conformance, so the coverage record is anchored to that evaluation.
How long should coverage records be retained?
Keep them indefinitely. Historical coverage records show how conformance has progressed over time, which is useful for documentation, procurement requests, and legal context if a question ever arises.
Coverage tracking turns an audit from a one-time deliverable into a living record. Scope, criteria, issues, and status sit in one place, and the team always knows where conformance stands.
See how Accessibility Tracker maps audit coverage end to end. Contact Accessibility Tracker to learn more.