To set up your first scan, choose a scanner type that fits your environment, point it at a representative page, run the check against a defined WCAG version and level, then review the flagged items. The first scan is meant to give you a baseline view of automatically detectable issues, not a full picture of conformance. Most teams complete an initial scan in under an hour once the tool is installed and the target page is selected.
| Step | What It Involves |
|---|---|
| Pick a tool type | Browser extension, command-line scanner, or API-based scanner depending on your workflow. |
| Define the target | Start with one representative page, typically the homepage or a high-traffic template. |
| Set the standard | Configure the scan to evaluate against WCAG 2.1 AA or 2.2 AA. |
| Review results | Read each flagged item, its location, and the criterion it references. |
| Know the limits | Scans detect approximately 25% of accessibility issues. The rest requires human evaluation. |
Choose a Scanner Type That Fits Your Workflow
Accessibility scanners come in a few main categories. Browser-based scanners run as extensions and check the page currently loaded in your tab. Command-line scanners run from a terminal and work well for developers who want to check pages during builds.
API-based scanners integrate into pipelines and can be called programmatically. Open source scanners are available across all three categories.
For a first scan, a browser extension is the easiest entry point. It requires no setup beyond installation, and you can see results within seconds on any page you have open.
Pick the Right Page to Start With
Do not start with a random page. Choose one that represents a template or layout used across the site. A homepage, a product page, or a primary content template are common starting points.
Pages behind a login require authenticated scanning, which means the scanner must run inside an active session, usually through a browser extension that inherits your login state.
Scanning a single page first lets you learn the tool’s output format before processing larger sets of results.
Configure the Scan Against a WCAG Version
Most scanners let you select which version of the Web Content Accessibility Guidelines (WCAG) to evaluate against. The two common options are 2.1 AA and 2.2 AA. Pick the version that matches your conformance target.
If your organization has not set a target, 2.1 AA is the most widely referenced standard, including in the U.S. Department of Justice’s Title II rule.
Read the Results Carefully
Scan output includes the rule that was checked, the element on the page where the issue appears, and a short description of what the scanner identified. Some items will be clear pass or fail results. Others will be flagged as needing review, meaning the scanner cannot determine pass or fail on its own and a person has to look at the element in context.
Treat review items with the same attention as failures. They often point to the issues that scans cannot resolve automatically.
Understand What the Scan Did Not Cover
A single scan evaluates HTML, CSS, and ARIA attributes against rule logic. It does not evaluate whether content makes sense to a screen reader user, whether interactive elements work with a keyboard alone, or whether visible focus order matches the reading order. These require manual evaluation, including screen reader testing and keyboard testing.
The 25% detection figure is a useful reminder. Your scan results are a starting point, not a complete view of accessibility.
Plan the Next Step
After your first scan, you have a list of automatically detectable issues for one page. From there, options include expanding to more pages, scheduling recurring scans for monitoring, or pairing scan results with a manual audit to identify the issues scans cannot catch.
Each direction depends on how deep you need to go and what your conformance goal looks like. A first scan is the smallest possible commitment to learning where a site stands, and the value comes from what you do with the information after.