Public documentation
Previous scan and history
How local scan history and comparison should be interpreted without claiming regression proof by themselves.
Purpose
Previous scan and history features help reviewers compare local evidence over time, reopen context, and support remediation follow-up. They are convenience and traceability features, not a guarantee that every regression or fix was detected.
What history can store
| Stored item | Use | Boundary |
|---|---|---|
| Scan summary | Compare counts and categories across local scans. | Counts can change because page state, viewport, auth, or rules changed. |
| Issue identity and status | Track local review decisions and remediation state. | Selectors can become stale after DOM changes. |
| Diagnostics and limitations | Explain why a scan did or did not cover a state. | Diagnostics are not user-page failures. |
| Contrast review state | Keep item-level decisions and report inclusion where supported. | Review decisions still need human verification. |
| Workflow notes | Preserve review context for handoff. | Notes can contain sensitive project information. |
Comparison workflow
- 1
Scan a stable state
Use the same route, auth state, viewport, and interaction state when comparison matters.
- 2
Review changed counts
Look for new, resolved, and changed items, then inspect the evidence behind each difference.
- 3
Check limitations
Confirm that differences are not caused by reduced coverage, blocked frames, timeouts, or page state changes.
- 4
Retest manually
Use manual and assistive technology testing for important user journeys before release decisions.