Accessibility Scanner

Every playtest already includes an accessibility scan, but only of the single page the flow's last step happened to end on (see Issues & Accessibility Scanning). The Accessibility Scanner is different: give it a starting URL, and it crawls your whole site, running a full WCAG scan on every page it finds, no scripted steps required. It's the right tool when the question is "is my site accessible," not "does this one flow work."

Creating a scan

Go to My Runs → New Accessibility Scan, or A11y Scans in the top nav. Fill in:

• Starting URL: where the crawl begins.
• Max pages: how many pages to scan before stopping, up to 30. VeriWasp follows same-origin links it finds on each page it scans (a breadth-first crawl), starting from your starting URL, until it either runs out of new pages to find or hits this cap.
• Label (optional): a name for this scan.

Creating a scan costs nothing, the same two-step model as a playtest or API test. Nothing is charged until you trigger it.

How the crawl works

VeriWasp visits your starting URL, scans it, then looks for links to other pages on the same site and queues them up, repeating until it hits your max pages limit. Only same-origin links are followed; external links are ignored entirely. A page that fails to load (a broken link, a 404, a page requiring credentials VeriWasp doesn't have) is recorded as failed and the crawl moves on to the next queued page rather than stopping the whole scan, since a single dead link on a real site is common and shouldn't block scanning everything else.

Reading the results

Unlike a playtest's flat issue list, violations here are grouped by rule across every page scanned: "Elements must meet minimum color contrast ratio thresholds" affecting 5 pages and 72 elements reads as one finding, not 72 separate ones. Each finding shows:

• The rule's description and severity (mapped from axe-core's own impact rating, same table as a playtest's accessibility scan: critical/serious is high, moderate is medium, everything else is low).
• How many pages and elements it affects.
• An expandable list of exactly which pages, and how many elements on each.

Below the violations, a page list shows every URL the crawl visited and whether it loaded successfully.

Sharing

Every scan gets a public link at /a11y-report/{slug}, shown once it's been run: read-only, no trigger button, same content as the private detail page.

Triggering from CI/CD

Like a playtest or an API test, every scan gets its own secret trigger URL (shown on the detail page) that a deploy pipeline can POST to, at /a11y-scan-trigger/{token}.

Gate mode

Add ?wait=<seconds> to block until the scan finishes, same as a playtest's CI/CD gate mode, up to a 90 second maximum wait:

curl -X POST "https://veriwasp.com/a11y-scan-trigger/{token}?wait=60"

{
  "run_id": "3f1e2c9a-...",
  "status": "completed",
  "report_url": "https://veriwasp.com/a11y-report/f8a2c1",
  "pages_scanned": 6,
  "pages_failed": 1,
  "violations_found": 5
}

If the wait budget runs out first, you get the same fire-and-forget response as not passing ?wait= at all, plus a status_url you can poll yourself at /api/a11y-scans/{slug}/status.

There's no regressions_found or ?gate=regression support for this run kind yet: scans don't have a baseline/previous-scan comparison the way playtest regression detection does, so there's nothing to gate on beyond status itself.

Pricing

A scan costs a flat 1 credit regardless of how many pages it crawls, up to its max pages cap, the same starting rate as a playtest or API test.