Prerequisites for running an accessibility scan: defined scope, page list, authentication access, WCAG version selection, and a plan for the results.

Before running an accessibility scan, you need a defined scope, a list of pages or screens to evaluate, access credentials for authenticated areas, a selected WCAG version and…

Before running an accessibility scan, you need a defined scope, a list of pages or screens to evaluate, access credentials for authenticated areas, a selected WCAG version and conformance level, and a plan for what to do with the results. Without these prerequisites, a scan produces data that is hard to act on and easy to misinterpret. The setup work takes minutes but determines whether the scan output is useful.

Accessibility Scan Prerequisites at a Glance
Prerequisite What It Means
Defined Scope The specific URLs, templates, or screens to be scanned, agreed on before the scan runs.
WCAG Version and Level The standard the scan checks against, typically WCAG 2.1 AA or 2.2 AA.
Authentication Access Credentials or session access for any pages behind a login.
Coverage Expectations Awareness that scans flag approximately 25% of accessibility issues.
Action Plan A defined process for triaging, assigning, and remediating identified issues.

Define the Scope of the Scan

Scope is the first prerequisite. Decide which pages, templates, or screens the scan will cover. A marketing site might include the homepage, top product pages, key landing pages, and shared templates. A web application might include the main dashboard, account settings, and primary user flows.

Scanning every page on a large site produces noise. Scanning a representative sample of unique templates produces signal. Most patterns repeat across pages, so a well-chosen sample reflects the broader product.

Choose the WCAG Version and Conformance Level

Scans check against a specific version of the Web Content Accessibility Guidelines (WCAG). The selection matters because rules differ between versions. WCAG 2.1 AA is the most common reference standard and is the version cited under ADA Title II. WCAG 2.2 AA is increasingly requested for new projects.

Pick the version that matches your obligations or buyer requirements before the scan runs. Mixing versions across reports creates confusion when comparing results over time.

Prepare Access for Authenticated Pages

Public pages can be scanned without setup. Pages behind a login cannot. If the scope includes member areas, dashboards, checkout flows, or admin views, the scanner needs a way into those pages.

Authenticated page scanning usually requires a browser extension running within an active session or a configured set of credentials the scanner can use. Confirm which method your scanning tool supports and provision a test account with the right permissions before the scan runs.

Understand What the Scan Will and Will Not Catch

A scan evaluates HTML, CSS, and ARIA attributes against rules that can be checked programmatically. It flags approximately 25% of accessibility issues. The other 75% requires human evaluation: screen reader testing, keyboard testing, visual inspection, and code review.

Setting this expectation before the scan prevents the most common misreading of scan output, which is treating a clean scan as proof of conformance. A clean scan means the automated checks passed. It does not mean the page is accessible.

Plan What Happens After the Scan

A scan report is only useful if someone acts on it. Before running the scan, decide:

  • Owner: Who reviews the report and assigns issues.
  • Tracking: Where issues will live, whether in a conformance platform, a ticketing system, or a spreadsheet.
  • Prioritization: How issues will be ranked, typically by user impact and risk factor.
  • Validation: Who confirms fixes resolved the issue without introducing new ones.
  • Cadence: Whether the scan runs once or on a recurring schedule.

Decide Between One-Time and Recurring Scans

A single scan is a snapshot. Recurring scans, run on a daily, weekly, or monthly schedule, show whether issues are being introduced over time. If the product changes often, monitoring is more useful than a one-time check. If the product is static, a one-time scan may be enough until the next significant update.

This decision affects how the scanning tool is configured and how the results integrate with the rest of an accessibility program. For broader context on how scans fit into a larger evaluation strategy, see the accessibility scan setup overview.

The prerequisites above turn a scan from a raw data dump into a useful input for an accessibility program. The few minutes spent on setup pay off across every report the scan produces.