A single-page scan evaluates one URL at a time. A site-wide scan crawls multiple pages, sometimes an entire domain, in a single session. Both check for the same types of accessibility issues, but they differ in scope, speed, and the scenarios where each is most useful.
| Key Point | What It Means |
|---|---|
| Scope | Single-page scans check one URL. Site-wide scans crawl dozens, hundreds, or thousands of pages. |
| Detection | Both types flag approximately 25% of total accessibility issues. The remaining 75% requires human evaluation. |
| Speed | Single-page scans return results in seconds. Site-wide scans take longer depending on the number of pages crawled. |
| Best Use | Single-page scans work well for spot checks. Site-wide scans are better for identifying patterns across a domain. |
What a Single-Page Scan Covers
A single-page scan loads one URL and evaluates its HTML, CSS, and ARIA attributes against Web Content Accessibility Guidelines (WCAG) success criteria. It checks that specific page for issues like missing form labels, incorrect heading order, and missing alternative text on images.
This type of scan is useful when a developer publishes a new page and wants immediate feedback. It is also practical for checking a specific template, landing page, or login screen in isolation.
The limitation is visibility. A single-page scan tells you nothing about the rest of the site. Two pages built from different templates may have entirely different issues, and scanning one will not surface what exists on the other.
What a Site-Wide Scan Covers
A site-wide scan starts at a given URL and follows links to crawl additional pages across the domain. It applies the same automated checks to every page it reaches, producing a report that spans the entire crawl.
The primary advantage is pattern detection. If every product page is missing the same form label, a site-wide scan will flag that issue repeatedly, making it clear the problem originates in a shared template rather than a single page. This kind of insight is difficult to get from scanning pages one at a time.
Site-wide scans also produce aggregate data. Organizations can see which page types have the highest concentration of issues, track totals across the domain, and prioritize remediation based on volume and user impact.
Where Both Types Fall Short
Neither scan type replaces a manual audit. Automated scans, whether applied to one page or a thousand, flag approximately 25% of accessibility issues. The other 75% involves context, interaction patterns, and screen reader behavior that automated checks cannot assess.
Site-wide scans also depend on what pages the crawler can reach. Pages behind login walls, dynamically generated content, and single-page application views may not appear in a standard crawl. Authenticated scanning, which runs within an active browser session, addresses some of these limitations.
Choosing Between Single-Page and Site-Wide Scans
The choice depends on what you need at a given moment. Single-page scans fit into development workflows where a specific page needs a quick check before deployment. Site-wide scans fit into broader monitoring strategies where the goal is tracking WCAG conformance across an entire domain over time.
Most organizations use both. Developers run single-page scans during active work. Scheduled site-wide scans run weekly or monthly to catch regressions and new issues as content changes.
The two approaches are complementary, and neither replaces the need for human evaluation of the 75% of issues that automation cannot detect.