How to Scope an Accessibility Audit — Planning Guide

Most accessibility audits fail not because the auditors lack skill, but because the scope was wrong from the start. An audit that covers every page of your application at equal depth will take months, cost a fortune, and produce a report so thick that no one reads it. An audit that covers only your homepage will miss the barriers that actually hurt your users. The key is scoping: choosing the right flows, the right depth, and the right deliverables so that the audit produces results your team can act on immediately.

Why Scoping Matters

Accessibility audits are expensive in time and expertise. A typical manual audit of a single page or flow against WCAG 2.2 Level AA takes two to four hours for an experienced auditor. If your application has hundreds of pages and dozens of interactive components, you cannot audit everything in a single engagement. Scoping forces you to focus your investment where it matters most — on the user flows that reach the most people and where barriers cause the most harm.

Poor scoping also leads to poor remediation. When a development team receives a 200-page audit report covering the entire application, the result is paralysis. No one knows where to start. Issues pile up in a backlog and never get fixed. A well-scoped audit produces a focused report with clear priorities that maps directly to sprint work.

Choosing Flows to Audit

Start by identifying your application's critical user journeys. These are the paths that users must be able to complete to get value from your product. For an e-commerce site, that might be: search for a product, view product details, add to cart, and checkout. For a SaaS application, it might be: sign up, configure your account, complete the core task (writing a document, creating a project, sending a message), and manage your subscription.

Prioritize flows based on three factors:

Traffic volume: Flows that the most users touch should be audited first. An accessibility barrier on your most-visited page affects more people than a barrier on a settings page.
Business criticality: Flows that drive revenue or are legally sensitive (such as account creation, checkout, or compliance-related features) should be prioritized.
Barrier likelihood: Flows with complex interactions — modals, dynamic forms, drag-and-drop, data visualization — are more likely to have accessibility barriers than static content pages.

A good first audit typically covers five to ten flows. This is enough to identify systemic issues (problems that repeat across the application because they originate in shared components) while keeping the engagement manageable.

Defining Severity

Every issue found in an audit needs a severity rating so your team knows what to fix first. We recommend a four-level framework:

Critical: The user cannot complete the task at all. The barrier completely blocks access. Examples: a form that cannot be submitted with a keyboard, a checkout flow that traps screen reader users in an infinite loop, essential content conveyed only through color.
Serious: The user can complete the task but with great difficulty or by relying on workarounds. Examples: missing labels on form fields that require screen reader users to guess what input is expected, focus order that jumps erratically through a modal, images conveying important information without alt text.
Moderate: The user is inconvenienced but can complete the task without excessive effort. Examples: insufficient color contrast on secondary text, missing skip navigation links, status messages not announced to screen readers.
Minor: A best-practice violation that has minimal impact on task completion. Examples: redundant ARIA roles on native HTML elements, suboptimal heading hierarchy, decorative images with non-empty alt text.

Severity should be based on the impact to users, not on how easy the fix is. A critical issue that takes five minutes to fix is still critical. A minor issue that requires a major refactor is still minor. Effort estimation belongs in your sprint planning, not in the audit severity rating.

Structuring Audit Deliverables

The best audit report is one your team actually uses. Structure deliverables for action:

Executive summary: One page. Overall conformance assessment, number of issues by severity, top three systemic patterns, and recommended next steps. This is for stakeholders who need to understand the situation without reading every finding.
Issue detail: Each finding should include the WCAG success criterion violated, the severity rating, a description of the barrier and who it affects, steps to reproduce the issue, a screenshot or screen recording, and a recommended fix. If the issue is in a shared component, note everywhere it appears.
Systemic patterns section: Group issues that share a root cause. If every dropdown in your application has the same ARIA problem, that is one fix applied in one component — not fifty separate issues. This section saves your team enormous time.
Sprint-ready format: Deliver findings in a format your team already uses. If your team works in Jira, deliver issues as a CSV that can be bulk-imported. If they use Linear or GitHub Issues, format accordingly. The fewer steps between "audit complete" and "issues in the backlog," the more likely they get fixed.

Avoiding Bloated Reports

Common audit antipatterns to watch out for:

Listing every instance of a systemic issue as a separate finding. If you have 40 images missing alt text across 10 pages, that is one finding with a note about scope, not 40 findings.
Including pages of WCAG educational content. Your development team needs to know what to fix, not the history of the W3C. Link to resources for context, but keep findings focused.
Auditing pages that are out of scope for the current engagement. Stick to the agreed scope. Note anything alarming you spot outside scope as a "flag for future audit," but do not inflate the report with findings outside the agreed flows.

Making Results Sprint-Ready

The gap between receiving an audit report and fixing the issues is where most accessibility efforts stall. Close that gap by involving your development team in the scoping process from the start. When developers help choose which flows to audit, they already have context on the findings before the report lands. Schedule a findings walkthrough meeting where the auditor presents the results to the development team, answers questions, and helps translate findings into development tasks. Finally, set a target: remediate all critical and serious issues within a defined number of sprints, and build moderate and minor issues into your regular backlog.