Comparing & Consolidating Scans

Once you have more than one accessibility scan, two questions come up:

1. "Did our last release fix what we said it did?" — answered by Compare.
2. "What does our overall accessibility look like across these N independent scans?" — answered by Consolidate.

TestKase ships both as first-class reports.

Compare two runs of the same scan

Use Compare when a single scan runs on a schedule (or you've manually re-run the same scan multiple times) and you want a focused diff between any two of those runs.

When to use it

• Verify a release: compare the run from before deploy with the run from after.
• Track regressions over a quarter: compare run #1 with run #12.
• Sign off on an audit fix: compare the audit-time run with the post-fix run.

How it works

• Open the scan and go to its Scan history.
• Choose any two runs from the history (e.g. #3 and #7).
• TestKase auto-orders them oldest-first and builds a side-by-side diff:
  • Score comparison with the delta (+12, -3)
  • New — present in the newer run, absent in the older
  • Retained — present in both
  • Resolved — present in the older run, gone in the newer
  • Severity breakdown, and per-page and per-component (CSS selector) rollups for each of the three

Open the report

• From the scan list, open the scan → Scan history tab → tick two runs → Compare → in the Compare Scan Versions dialog, confirm with Compare.
• Direct link: /web-scanner/compare?scanId=<id>&version=<older>,<newer> (the two run numbers, comma-separated).

API

POST /api/v1/accessibility-scans/compare
Content-Type: application/json
{
  "rootScanId": 191,
  "versions": [3, 7]
}

Order doesn't matter — the backend sorts the two versions oldest-first before producing the diff.

Paginated issues from the comparison:

POST /api/v1/accessibility-scans/compare/issues?page=1&limit=25
Content-Type: application/json
{ "rootScanId": 191, "versions": [3, 7] }

Every issue in the response carries a diffStatus of new, retained, or resolved, and the list is ordered new → retained → resolved. Filtering server-side is not supported on this endpoint — filter on diffStatus client-side.

limit is capped at 200 (default 50); a larger value is rejected with a 400. Page through the rest.

Limits

• Exactly two versions per compare call. For multi-run trend analysis, run sequential compares or wait for the trend dashboard.
• Both versions must belong to the same root scan (same URL list, same WCAG settings — that's what makes the diff meaningful).
• Both runs must have finished (Completed). Comparing against a run that failed or is still running returns an error.
• Compare only reads runs you created. A scan shared with you through an accessibility team opens as a report, but you cannot compare its runs — the request is refused with "Scan version N not found". Ask the scan's creator to run the comparison. (Consolidate is different — see below.)

Consolidate multiple independent scans

Use Consolidate when you have separate scans (different URLs, different times, different scan groups) and you want one combined view — typically for an audit or stakeholder presentation. Consolidation accepts both Web Scanner scans and Chrome-extension (Workflow Analyzer) scans, and you can mix the two types in a single consolidated report.

When to use it

• Your site has 5 scan groups (marketing, app, docs, pricing, blog) and you want one combined accessibility score for the company.
• You ran independent scans for different products and want to share a single report with a stakeholder.
• You're producing an end-of-quarter compliance summary across many scan groups.

How it works

• Pick two or more completed scans — Web Scanner scans, Chrome-extension (Workflow Analyzer) scans, or a mix of both. For each one TestKase uses its most recent run.
• Results are deduplicated by URL — if the same URL appears in more than one selected scan, the most recently scanned copy wins and only that scan's issues for that URL are counted. Then it produces:
  • A combined accessibility score across the deduplicated pages, weighted by issue severity
  • Per-scan and overall rollups
  • A WCAG 2.1 AA conformance summary across all included URLs
  • Affected-pages and affected-components tables that span every included scan

Open the report

• Scan list → multi-select scan rows → Consolidate reports. Only Completed rows are selectable.
• Direct link: /web-scanner/consolidate?ids=web-12,extension-47,…. Each id is a type-qualified scan ref — web-<id> for a Web Scanner scan and extension-<id> for a Chrome-extension (Workflow Analyzer) scan — so you can mix the two types in one link. A bare number (e.g. ?ids=1,2) still works and is treated as a Web Scanner scan.

Export as PDF

The consolidated report can be exported as a single PDF for executive sharing, audits, and compliance attestations:

POST /api/v1/accessibility-scans/consolidate/export-pdf
Content-Type: application/json
{ "scanRefs": ["web-12", "extension-47", "web-88"] }

Returns application/pdf — attachment; filename="consolidated-report.pdf".

API

POST /api/v1/accessibility-scans/consolidate
Content-Type: application/json
{ "scanRefs": ["web-12", "extension-47", "web-88"] }

Each entry in scanRefs is a type-qualified ref: web-<id> for a Web Scanner scan or extension-<id> for a Chrome-extension (Workflow Analyzer) scan. A bare number is accepted for back-compat and treated as a Web Scanner scan. The same scanRefs payload is used by all three consolidate endpoints.

Paginated issues:

POST /api/v1/accessibility-scans/consolidate/issues
?page=1&limit=25&impact=serious
Content-Type: application/json
{ "scanRefs": ["web-12", "extension-47", "web-88"] }

Limits

• Minimum two scan refs (Web Scanner, Chrome-extension, or a mix).
• Every selected scan must be Completed — one that is pending, running, or failed causes the whole consolidation to fail, it is not skipped. (Rows that aren't complete aren't selectable in the UI.)
• Consolidation does accept team-shared scans, unlike Compare: a scan shared with you through an accessibility team can go into a consolidated report alongside your own, and the combined score, WCAG summary, rollup tables and the PDF export all include it.
• Team access applies uniformly to shared scans. For a scan shared with you through an accessibility team, both the consolidated summary and the per-issue list below it load — the issue list draws on the same team-share access the report does, so a team member sees that shared scan's issues alongside their own (team members can already open those scans, so this is not a leak). The PDF export reflects the same combined data. A scan you have no access to at all still can't be consolidated.

Compare vs Consolidate — which one?

Related

• Managing scans
• Summary & Score
• Export formats
• Sharing scans