webscan

Webscan Documentation

Lesson 10 · Retests & auto-verify

Phase 2 · Triage & the fix workflow — Lesson 10 of 21 · All lessons

Objective: understand what a retest is, prove a fix actually works (by hand or automatically), and close the loop on an issue with confidence.

Before you start: an issue you've been working on (Lessons 7–9).

What is a retest?

Retest — checking a fixed issue to confirm the accessibility barrier is really gone before you close it. It's the difference between "we changed something" and "we verified it works." Skipping it is how issues get closed while the barrier quietly remains.

A retest has two properties:

  • Outcome — the result: Pending (not checked yet), Passed (the barrier is gone), or Failed (it's still there).
  • Method — how it was checked: Manual verification (a person tested it) or Automated re-scan (webscan scanned the page again and looked for the finding).

All of an issue's retests are listed in the Retest history panel, so you can see every attempt and its result over time.

Option A · Automated re-scan ("Auto-verify")

For issues from automated (axe-core) findings, webscan can verify the fix itself. Choose Auto-verify fix. Optionally give a Preview URL — a staging or preview address where the fix is already live — or leave it blank to re-scan the live page.

Webscan then re-scans that page and checks whether the specific finding still appears:

  • if it's gone → the retest Passes;
  • if it's still there → the retest Fails.

This is the fastest way to close the loop, and it's the step referenced in Lesson 9: after you merge a code-fix pull request, running Auto-verify is what earns the draft its Verified by re-scan badge — an honest statement that the scanner no longer sees the violation.

Preview URL vs live page: use a preview URL to verify a fix before it ships to production; leave it blank to confirm a fix that's already live.

Option B · Manual verification

Automated checks can't judge everything — some barriers need a human (testing with a screen reader, checking keyboard navigation, using judgement about context). For those:

  1. Choose Request manual retest — this records a new retest with the outcome Pending and method Manual verification.
  2. When someone has tested it, open that pending retest and use Record verification: set the outcome (passed/failed) and add notes describing what was tested and how.

Manual retests are also right whenever the finding came from a manual audit (Phase 3) rather than the automated scanner.

How retests move the issue forward

Retests drive the tail end of the issue lifecycle you met in Lesson 7:

  • An issue believed fixed sits at Ready for retest.
  • A passing retest moves it toward Verified — safe to Close.
  • A failing retest sends it to Failed retest — the fix didn't work, so it goes back to In progress.

So the honest loop is: fix → retest → (passed) verify & close, or (failed) fix again. An issue should never reach Closed without a passing retest behind it.

Tips & pitfalls

  • Never close on faith. "The developer says it's fixed" is not a retest. Re-scan or manually verify first.
  • Match the method to the barrier. Use Auto-verify for things the scanner can see (missing labels, contrast); use manual verification for experience-level barriers (keyboard traps, screen-reader flow) — the automated re-scan can't judge those.
  • A failed retest is progress, not a setback. It caught a fix that didn't work before it reached your users.
  • Write manual retest notes. "Tested with NVDA on Chrome, focus order now correct" is worth far more later than a bare "passed."

Recap

  • A retest proves a fix works before you close the issue; it has an outcome (Pending/Passed/Failed) and a method (Manual/Automated).
  • Auto-verify re-scans (a preview URL or the live page) for automated findings — and grants the Verified by re-scan badge after a merged fix.
  • Request manual retest + Record verification covers barriers a human must judge.
  • Retests drive Ready for retest → Verified/Failed retest; never Close without a pass.

Try it yourself

Take your issue through the full loop: mark it Ready for retest, run Auto-verify fix (or request a manual retest and record the result). If it passes, set the issue to Verified and close it. You've now completed one barrier end-to-end — the core of everything webscan does.

Previous: ← Lesson 9 · Connect your source code Next: Lesson 11 · Authenticated scanning →