webscan

Webscan Documentation

Lesson 5 · Anatomy of a finding

Phase 1 · Foundations — Lesson 5 of 21 · All lessons

Objective: read a single finding in full — what's broken, where, why it matters, and how to fix it — so a raw scan result becomes something you can act on.

Before you start: a completed scan from Lesson 4. Open one finding to follow along.

Why one finding at a time

The scan list tells you how many problems exist. The finding page tells you everything about one of them. This is the screen accessibility specialists live in, so it's worth learning every section.

Open any finding (click it in the scan's findings list). You'll see these sections.

The title and severity

At the top: the finding's title (a plain description like "Buttons must have discernible text") and its impact/severity (Critical / High / Medium / Low). This is the same severity you saw in the scan summary, repeated here for context.

There's also a Create remediation issue button — the bridge into the fix workflow. Ignore it for now; that's Lesson 7.

Affected page

The exact URL where webscan found this problem. A single rule can fail on several pages; each becomes its own finding tied to the page it was found on. Knowing the page is the first step to reproducing it yourself.

Affected elements

This is the heart of the finding. Webscan lists each element that failed the rule, and for every one shows:

  • Selector — a CSS selector that points at the exact element in the page, so you (or a developer) can find it immediately in the DOM.
  • HTML — the actual markup snippet that failed, so you can see the problem in context.
  • How to fix — a short, element-specific failure summary explaining why this element failed and what would satisfy the rule.

If a rule fails on ten buttons, you'll see ten elements here — each with its own selector and fix note. That per-element detail is what makes a finding actionable rather than just a warning.

Rule information

The "why it matters" section:

  • Rule — the underlying check (usually an axe-core rule) that flagged this.
  • WCAG tags — the Web Content Accessibility Guidelines success criteria this maps to (e.g. 4.1.2 Name, Role, Value). This is what makes findings defensible in a formal audit and connects them to the standard.
  • Review state — where this finding is in its lifecycle (e.g. still needs a human verdict, or already verified).
  • Open remediation guidance — a link to fuller documentation on the rule and how to fix it.

Reviewer verdict

At the bottom is the Reviewer verdict panel. This is where a human records a judgement on the finding — Confirmed barrier, False positive, Accepted / won't fix, or Needs more info — with optional notes, then Save verdict.

You can set it now, but how to decide is exactly what the next lesson is about, so we'll leave it until then.

Reading a finding well: a mini-method

When you open a finding, ask in order:

  1. What is the rule and its WCAG criterion? (Rule information)
  2. Where is it — which page and which elements? (Affected page + elements)
  3. Why did this element fail? (the per-element "How to fix")
  4. Is it real? — which you'll answer in Lesson 6.

Do that four-step read a few times and findings stop being intimidating.

Tips & pitfalls

  • Trust the selector, verify in the browser. The selector points at the element, but always confirm the problem in a real browser — it builds your judgement and catches the occasional false positive.
  • One finding, many elements is normal. Don't mistake ten failing buttons for ten separate problems; it's usually one missing pattern repeated.
  • WCAG tags are your credibility. When you report to a client or manager, cite the criterion — it turns "the tool complained" into "this fails WCAG 4.1.2."

Recap

  • A finding page has: title/severity, affected page, affected elements (selector + HTML + how-to-fix), rule information (rule + WCAG + guidance), and the reviewer verdict panel.
  • The per-element detail is what makes a finding actionable.
  • WCAG tags connect each finding to the standard.
  • Read every finding what → where → why → is it real.

Try it yourself

Open your top Critical finding and narrate the four-step read out loud. Find the failing element in your site's HTML using the selector. Don't set the verdict yet — you'll do that with intent in the next lesson, which begins Phase 2.

Previous: ← Lesson 4 · Run your first scan Next: Lesson 6 · Verdicts →