Webscan Documentation

Lesson 6 · Verdicts — deciding what's real

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

Objective: understand what a verdict is, why it exists, and how to record one — so you can turn a noisy list of scan results into a trustworthy list of real problems.

Before you start: a completed scan with findings (Lesson 5).

First, the key terms

Finding — a single problem that a scan reported on a specific page. A finding is a candidate: the tool thinks something might be wrong, but it hasn't been confirmed by a person.

Verdict — your recorded decision about whether a finding is actually a real accessibility problem. A verdict is how a human turns a machine's guess into a fact. Until a finding has a verdict, it's just an unreviewed candidate.

False positive — a finding that the tool flagged but which isn't really a problem when you look closely (for example, a decorative image the tool thought needed alternative text, but which is correctly hidden from assistive technology). Automated checkers always produce some false positives; that's normal and expected.

The short version: a scan produces findings; you give each finding a verdict; the verdict is what everyone downstream trusts.

Why verdicts matter

Automated accessibility tools are fast but not perfect. They can flag things that are fine, and they can't judge context. If you treated every raw finding as a real bug, you'd waste time fixing non-problems and lose your team's trust in the tool.

Verdicts solve this. They let you:

  • separate real barriers from noise, so your fix list is honest;
  • create a defensible record — "a human reviewed this and decided X";
  • teach webscan — over time your verdicts train webscan to predict which findings are likely real (more on that below and in Phase 4).

The four verdicts

On any finding page (see Lesson 5), the Reviewer verdict panel lets you choose one of four decisions:

Verdict Use it when…
Confirmed barrier You've checked and this is a genuine accessibility problem that should be fixed.
False positive The tool flagged it, but it isn't actually a problem.
Accepted / won't fix It's a real issue, but your team has consciously decided not to fix it (for a documented reason — e.g. a third-party widget you can't change).
Needs more info You can't decide yet — it needs investigation, or input from someone else.

Add a short note explaining your reasoning, then choose Save verdict. The note is invaluable later — for your future self, your teammates, and any audit trail.

Review state: where a finding is in its life

Separately from your verdict, each finding has a review state — a label showing how far along it is:

  • Automatically detected — freshly found by a scan, not yet reviewed.
  • Needs human review — flagged as awaiting a person's judgement.
  • Verified failure — a human confirmed it is a barrier.
  • Verified pass — confirmed resolved / not a problem.

You'll recognise these from the review state filter on the scan results page. Recording a verdict is what moves a finding out of "needs review" and into a verified state.

The Suggest button: webscan's prediction

On the verdict panel you may see a Suggest option. This asks webscan to predict a likely verdict, with a confidence level, based on patterns learned from verdicts your organisation has recorded before.

Two things to understand:

  • It's a suggestion, not a decision. It can speed you up on obvious cases, but the human verdict is always yours to set.
  • It gets better as you record more verdicts. This is the "teaching webscan" idea — you'll see how the underlying verdict model is trained in Phase 4.

A simple triage routine

Faced with a long findings list, work like this:

  1. Filter to Critical and High first (biggest impact).
  2. Open each finding, do the four-step read from Lesson 5 (what → where → why → is it real).
  3. Record a verdict with a one-line note.
  4. Anything you mark Confirmed barrier, carry forward into an issue (that's the next lesson).

Tips & pitfalls

  • Always leave a note, especially for False positive and Accepted / won't fix — six months later, "why did we skip this?" needs an answer.
  • "Accepted / won't fix" is not the same as "false positive." One says "real, but not now"; the other says "not real." Keeping them distinct keeps your data honest.
  • Don't rubber-stamp the Suggest button. Treat it as a hint, particularly early on when it has little of your data to learn from.

Recap

  • A finding is a candidate; a verdict is your human decision about it.
  • The four verdicts: Confirmed barrier, False positive, Accepted / won't fix, Needs more info — always with a note.
  • Review state tracks a finding's lifecycle from automatically detected to verified.
  • Suggest predicts a verdict from your past decisions — a hint, never the final word.

Try it yourself

Give verdicts to your five highest-severity findings, each with a one-line note. Mark at least one as a Confirmed barrier — you'll turn it into a trackable issue in the next lesson.


Previous: ← Lesson 5 · Anatomy of a finding Next: Lesson 7 · Issues — tracking a fix →