Setting up an accessibility scan involves configuring a scanner to evaluate web pages against Web Content Accessibility Guidelines (WCAG) success criteria. The process includes selecting which pages to scan, setting authentication for protected content, choosing which WCAG version and conformance level to evaluate against, and establishing a schedule for ongoing monitoring.
| Setup Step | What It Involves |
|---|---|
| Page Selection | Defining which URLs the scanner will evaluate, either through a sitemap, URL list, or crawl configuration |
| Authentication | Providing login credentials or session access so the scanner can reach pages behind authentication walls |
| Conformance Target | Selecting the WCAG version and level the scan checks against, typically WCAG 2.1 AA or WCAG 2.2 AA |
| Schedule | Setting a recurring scan frequency: daily, weekly, monthly, or a custom interval |
| Scope Limits | Restricting the scanner to specific domains, subdomains, or URL patterns to avoid scanning unintended content |
Selecting Pages for an Accessibility Scan
Most scanners accept pages in one of three ways: a sitemap URL, a manually entered list of URLs, or a crawl that starts at a root page and follows links automatically. Each approach has trade-offs.
Sitemap-based setup is the fastest for large sites. The scanner reads the XML sitemap and queues every listed URL. If the sitemap is incomplete or outdated, some pages will be missed.
Manual URL lists give precise control. This works well for smaller sites or for targeting specific templates, such as the homepage, a product page, a form page, and a content page. Scanning one representative page per template type can provide a useful baseline without scanning thousands of pages.
Crawl-based setup is thorough but less predictable. The scanner follows every internal link it encounters, which may include staging pages, admin panels, or duplicate content. Scope limits help contain the crawl.
Configuring Authentication for Protected Pages
Public pages require no extra setup: the scanner loads them directly. Pages behind a login require additional configuration.
Browser-based scanners typically manage authentication through a browser extension running within an active session. The user logs in normally, and the extension scans pages while the session remains open. This is the most reliable method for single-page applications and sites with complex authentication flows.
API-based and command-line scanners usually accept credentials as part of the configuration. Some support cookie injection or token-based authentication. The scanner uses these credentials to access protected pages during each scan run.
Without authentication, the scanner only evaluates publicly accessible content. For any web application with user accounts, dashboards, or gated content, authenticated scanning is necessary to get a complete picture.
Choosing a WCAG Conformance Target
The conformance target tells the scanner which WCAG success criteria to check against. WCAG 2.1 AA is the most commonly referenced level in legal and regulatory contexts, including ADA Title II requirements. WCAG 2.2 AA is the current version and is backward-compatible with 2.1.
Most organizations set their target at WCAG 2.1 AA or WCAG 2.2 AA. Setting the target at Level A alone leaves significant areas uncovered. Setting it at AAA is typically unnecessary for regulatory purposes and may generate results that are difficult to act on.
The conformance target does not change what the scanner can detect. Automated scans check HTML, CSS, and ARIA attributes against defined rules. They flag approximately 25% of WCAG issues. The remaining 75% requires human evaluation. The conformance target determines which rule set the scanner applies to its results.
Setting a Scan Schedule
A one-time scan provides a snapshot. Ongoing monitoring provides trend data. Most organizations benefit from scheduled scans that run at a regular interval.
Daily scans work well for sites with frequent content updates or active development. Weekly scans are a common default. Monthly scans are appropriate for stable sites with infrequent changes.
Scheduled scans serve two purposes. First, they catch new issues introduced by code deployments or content updates. Second, they confirm that previously identified issues have been remediated. Scan reports over time show whether an organization’s accessibility posture is improving, declining, or holding steady.
Defining Scope and Exclusions
Scope configuration prevents the scanner from evaluating content outside the intended target. Common scope settings include domain restrictions, subdomain inclusion or exclusion, and URL pattern filters.
For organizations with multiple subdomains, scope settings determine whether the scanner stays within www.example.com or also evaluates app.example.com and blog.example.com. Excluding third-party embedded content, such as iframes from external services, is also a standard configuration step.
URL pattern filters allow granular control. An organization might exclude /admin/* paths from public-facing scan reports while running a separate authenticated scan against those pages internally.
Reviewing Initial Results
After the first scan completes, the results show a count of flagged issues organized by WCAG success criterion, severity, and page. This initial report serves as a baseline.
Not every flagged item is an actual issue. Some results require manual verification. The scanner flags patterns that may indicate a WCAG issue, but context determines whether the flag is accurate. A human reviewer confirms or dismisses each flag based on the actual user experience.
Initial results also reveal whether the scan configuration is correct. Missing pages suggest a sitemap or crawl issue. Unexpectedly low issue counts may indicate the scanner could not access authenticated content. Reviewing the first scan’s coverage data is as important as reviewing the issues it identified.
What Scan Setup Does Not Cover
Automated scans, regardless of how well they are configured, detect approximately 25% of accessibility issues. The remaining 75% requires manual evaluation by a person who can assess screen reader behavior, keyboard interaction, reading order, and content meaning.
Scan setup is one component of an accessibility evaluation strategy. It provides repeatable, scalable detection of a specific category of issues. A full evaluation pairs scan results with a manual audit conducted by an accessibility professional to identify the issues that automated checks cannot reach.