Webscan Documentation
Lesson 7 · Issues — tracking a fix
Phase 2 · Triage & the fix workflow — Lesson 7 of 21 · All lessons
Objective: understand what an issue is, create one from a confirmed finding, assign it, discuss it, attach evidence, and drive it through its lifecycle.
Before you start: at least one finding you marked Confirmed barrier in Lesson 6.
What is an issue?
Issue — a trackable unit of work created from one or more findings. Where a finding just says "here's a problem," an issue adds everything you need to actually get it fixed and closed: an owner (the person responsible), a status (where it is in the process), a discussion thread, evidence, and a history of retests.
Think of the difference this way:
- A finding is a diagnosis — the scan noticed something.
- An issue is a ticket — a human is now accountable for resolving it.
This mirrors how issue trackers like GitHub Issues or Jira work, so your developers will feel at home.
Create an issue from a finding
- Open a finding you've confirmed and choose Create remediation issue. (Remediation simply means "the work of fixing an accessibility problem.")
- Webscan pre-fills a form from the finding. You can adjust: - Title — a clear, short summary of the problem. - Description — the detail: what's wrong, where, and why it matters. - Severity — Critical / High / Medium / Low, usually carried over from the finding. - Assigned to — the team member who will own the fix (optional at first).
- Save. You land on the issue page, which becomes the home for this piece of work.
Issues can also be created from a manual audit result (Phase 3) — the issue page will show its source finding or source checkpoint so you can always trace an issue back to where it came from.
The issue lifecycle (statuses)
An issue moves through a status — a label showing what stage it's at. Webscan's statuses are:
| Status | Meaning |
|---|---|
| Open | Created, not yet picked up. |
| Assigned | Given to an owner. |
| In progress | Someone is actively working on the fix. |
| Ready for retest | The fix is believed done and is waiting to be verified. |
| Failed retest | A retest showed the barrier is still present — back to work. |
| Verified | A retest confirmed the fix works. |
| Closed | Done and put to bed. |
You set the status (and severity, and assignee) from the Issue management panel's Update issue action. The Ready for retest → Verified/Failed retest steps are driven by retests, which you'll learn in Lesson 10.
Collaborate: discussion and evidence
The issue page has two collaboration tools:
- Discussion — a comment thread. Use Add comment to leave notes, ask questions, or record decisions. This keeps the conversation attached to the work instead of scattered across chat and email.
- Evidence — supporting material. Use Add evidence to attach a link or note (a screenshot URL, a reproduction, a reference). Evidence here means anything that documents the problem or proves the fix — it's what makes an issue defensible in a formal audit.
There's also Source evidence — code or markup tied to the issue — which becomes important when you connect your repository in Lesson 9.
Where issues live
All issues for a project are listed on the project's Issues page (reachable from
the project). That's your team's accessibility backlog: filter it, assign from it,
and work it down. Each issue also has a reference (a short ID like WS-…) so you can
refer to it in conversation.
Tips & pitfalls
- One barrier, one issue. Resist bundling unrelated problems into a single issue — small, focused issues are easier to assign, fix, and verify.
- Assign early. An unowned issue tends to sit. Even a provisional assignee moves it from Open to Assigned.
- Write the description for the fixer, not the tool. Say what a developer needs to know to reproduce and fix it — the scan already captured the technical rule.
- Keep the status honest. The lifecycle is only useful if it reflects reality; don't mark Verified until a retest actually passes.
Recap
- An issue turns a confirmed finding into trackable work with an owner, status, discussion, and evidence.
- Create one with Create remediation issue; manage it with Update issue.
- The lifecycle runs Open → Assigned → In progress → Ready for retest → Verified/Failed retest → Closed.
- Discussion and evidence keep the whole conversation and proof in one place.
Try it yourself
Turn your confirmed finding into an issue. Set its severity, assign it to yourself (or a colleague from Lesson 2), and add one comment describing how you'd reproduce it. Leave the status at Open — the fix comes next.
Previous: ← Lesson 6 · Verdicts Next: Lesson 8 · AI remediation assistance →