Getting Started
From adding a site to your first report takes a few minutes, most of it spent by the scan itself.
An accessibility scan is a one-time run against a website, bought one run at a time from One-Time Runs, like a pentest. It does not scan repositories or pull requests, and there is nothing to switch on first.
1. Verify your domain
Scans only run against domains your organization has proved it owns. If you already use Pentesting, your verified domains are shared and you can skip this step. Otherwise add the domain and publish the verification token as described in Domain Verification.
2. Add a site
Open One-Time Runs → Accessibility (WCAG) and fill in the form on the Sites tab:
| Field | What to enter |
|---|---|
| Verified domain | The domain the site belongs to |
| Start URL | Where the crawl starts, usually staging, for example https://staging.example.com |
| Name | Optional, shown on reports |
| Standard | WCAG 2.2 AA (default), 2.1 AA or 2.0 AA |
| Scan size | Quick, Standard or Deep; see Scan Modes and Pricing |
| Sign in before crawling | None, or a login form, Basic, Bearer token or Cookie |
| Ignore these elements | CSS selectors to leave out, such as a third-party chat widget |
| Skip these paths | Paths the crawl should not open, for example /admin/** |
| Check these pages first | Pages the crawl might not find on its own, such as key flows behind the login |
The start URL, the login page and every listed page must sit under the verified domain.
Signing in
Most of an application is behind a login, and a scan that cannot sign in only checks the login page. Give the scan a test account, never a real person's.
- Login form: the login page URL, a username or email and a password. The scan fills in the form and submits it, once.
- Basic: a username and password for HTTP Basic authentication.
- Bearer: a token sent as an
Authorizationheader to your site only. - Cookie: a session cookie header copied from a signed-in browser.
Credentials are encrypted when saved and never shown again. To change them, fill in the fields again; to keep them, leave the fields empty when you edit the site.
3. Check the site (free)
Select the Check site button on the site. In a few seconds it loads the start page the way the scanner will, without checking anything. With a Basic, Bearer or Cookie login it sends that login too; with a login form it checks the login page loads (the form itself is filled in when the scan runs). The site then shows either Ready to scan or the reason it cannot be scanned:
- Blocked by bot protection. Allow the scanner through on your staging
site. It identifies itself with
CodityAccessibilityScannerin its User-Agent; see Scope and Safety. - The site refused the login. Check the credentials saved for the site.
- An error, or a redirect elsewhere. For example an IP allowlist answering 403, or a start URL that redirects to another host (use the address it lands on instead).
- Not publicly reachable. The scanner runs from the internet and cannot reach a site that only resolves inside your network.
The same check runs automatically when you start a paid scan, if the site has not passed one since it was last edited, and a site that fails it is never charged for.
Two things only a full browser can find, so they show up in the scan itself rather than in this check: a login form that does not sign in (the scan then checks the pages reachable without signing in and says so), and bot protection that only challenges real browsers (the scan then stops and says what to allow). Those scans are charged like any other, so allowlist the scanner and test your login before running.
4. Run a scan
Select Run to pay by card, or the wallet button to pay from your organization's balance. One scan runs at a time per organization.
The scan appears in the Scans tab and updates as it goes. When it finishes, the person who started it gets an email with the totals and a link to the report. Open the report from the email or the Scans tab, and download it as a PDF to share.
