The scope for an accessibility audit defines what pages, screens, views, and/or content will be evaluated. Without a clear scope, the client will not know what the scope covers and the auditor won’t know exactly what is included in the audit.
The scope is the shared agreement on what is in and what is out. It protects both sides: the client knows what they’re paying for, and the auditor knows exactly what to evaluate.
| Scope Element | Example |
|---|---|
| Pages | Each unique page template on the site (home, product, blog post, contact) |
| Screens | Distinct screens within a web app (dashboard, settings, checkout) |
| Views | Any distinct view within a page or screen (tabs, multi-step flows, filtered results, authenticated states) |
| Exclusions | Anything explicitly not included in the audit |
Why Does Audit Scope Matter?
An audit without a defined scope produces inconsistent results. If the auditor doesn’t know which pages to evaluate, they’ll sample based on assumptions. Those assumptions may skip your most complex templates, authenticated workflows, or embedded content.
Scope also determines cost. A 10-page marketing site and a 50-screen web app require very different levels of effort. Defining scope upfront prevents mid-project surprises.
At Accessible.org, every audit engagement begins with a scope agreement before any evaluation starts.
Pages
Pages are the distinct page templates on a website. Auditors don’t need to evaluate every individual page if your site uses repeating layouts. A site with 100 pages may only have 12 distinct templates. Those 12 templates usually comprise the scope, not all 100 pages.
If a template repeats across dozens of URLs, one representative URL per template is enough. Listing specific URLs removes ambiguity. If a page isn’t listed, it isn’t evaluated.
Screens
Screens apply to web apps where different areas of the product have their own layouts and functionality. A dashboard screen is different from a settings screen. Each screen with a unique layout belongs in the scope.
A web app may load from a single URL but contain dozens of screens. Each one needs to be identified individually in the scope.
Views
Views are any distinct presentation within a page or screen. A page with three tabs has three views. A dashboard that changes by user role has a view per role. A multi-step checkout flow has a view per step.
Views are where scope definitions tend to get missed. A page may conform to WCAG in its default state but introduce issues when a different view loads. Each view needs to be listed in the scope individually.
The Accessibility Tracker Platform maps each issue to its specific page, screen, or view, which makes scope tracking straightforward across large projects.
What to Exclude from the Scope
Exclusions are as important as inclusions. Common exclusions:
- Third-party content you don’t control (social media embeds, ad networks)
- Documents (PDFs, Word files)
- Archived content not actively maintained
- Internal tools not used by the public
- Native mobile apps (these require separate audits)
Documenting exclusions prevents misunderstandings later. If someone asks why a specific page wasn’t covered, the scope provides the answer.
Do I need a separate scope for each website or app?
Yes. Each website, web app, or native mobile app should have its own scope. Templates, functionality, and WCAG criteria differ across properties. A combined scope creates confusion about what was actually evaluated on each product.
Should the scope specify a WCAG version?
Yes. The scope should name the exact WCAG version and conformance level the audit targets. WCAG 2.1 AA is the current standard for most organizations. Leaving the version implied weakens the audit report during procurement reviews and legal proceedings.
Can I add pages to the audit scope after it starts?
Most auditors allow scope adjustments, but additions affect timeline and cost. If you discover missed pages mid-audit, discuss the change with your auditor so they can adjust the engagement.
A well-defined audit scope is the foundation of a useful accessibility audit. It determines what gets evaluated and whether the results translate into real progress toward WCAG conformance.
Contact Accessible.org to define the right audit scope for your website or web app.