finding board

Sort an Accessibility Audit Into Act-First Order — Free

Paste audit findings and read them sorted into blocking, soon and watch lanes with the effort each one implies.

The proof surface

Audit lists are ordered by criteria; remediation is ordered by what blocks a task. The board converts one into the other, which is what a sprint needs.

Inputyour own audit findings, one per line

Rare devicetriages the reader's own audit findings by blocking effect and effort, instead of restating WCAG success criteria

Output artifacta three-lane board with blocking findings separated from cosmetic ones

Cost$0 · local-first · one free run · samples labelled

Sample, not your facts: Sample: keyboard-unreachable checkout button, contrast 3.1:1 helper text, focus trap in the cookie banner, 24 developer hours, 18 screens — four concrete points across four types.

Why the flat version breaks

Audit order as fix order

Findings arrive grouped by success criterion, so a cosmetic contrast issue can sit above a focus trap that stops keyboard users completing a purchase.

Fixing everything at once

A 40-item list spread across a sprint usually closes none of the blocking items, and the next audit repeats them.

Counting issues as progress

The number that matters to a release is blocking findings remaining, not total findings closed.

How to work the finding board

Paste the findings

One per line in your own words; severity words and component names are read from the text.

Enter the hours

Available developer hours turn the blocking lane into a plan rather than a wish.

Read the lanes

Blocking findings sit in the first lane, needs-fixing in the second and cosmetic in the third, with counts in the foot rule.

Assign and ship

Give the first lane an owner per finding and re-check the closest items after the sprint.

What the board replaces

Question	Before	On the board
What to fix first	work the list top down	blocking lane separated from watch lane
How much can fit	estimate mid-sprint	lane counts against the hours you have
What to tell stakeholders	'there are 40 issues'	the blocking count and the screens affected

Severity words matter: a finding marked blocking lands in the first lane, and one described as cosmetic lands in the third.

Run it on the samples, right here

FIRST-LOAD

Data note: Everything runs in this browser tab on the finding board: your audit findings stays on this device, nothing is uploaded, and the reading is rebuilt only when you press run.

Go deeper: the companion app files the same reading as a triage clipboard with three lanes

The article demo above runs without limits. The companion app keeps a local history, exports the rows as CSV, prints the ready-to-mail packet, and holds your drafts on this device — one free run, then $ 9 one-time for the layer that keeps filing.

The board and the lane counts are free. The paid layer prints the remediation register and keeps it across sprints.

Open the finding triage board companion

Boundary

This finding board works only on the audit findings you paste you paste. It does not certify conformance, does not replace a manual audit, and does not file an accessibility statement for you. The figures describe what you supplied, not what is true in the world. Confirm anything you plan to act on with a developer, and an accessibility specialist for anything touching assistive technology before you rely on it.

What this is built on

Every figure comes from the audit findings you paste you paste; nothing is looked up, scraped or asserted as verified.
Method: lanes are assigned by severity words and component names found in each line
Sample values are labelled samples — illustrative by design, not your data and not a quotation of any organisation's policy.

Before: the reader had a 40-item audit list. After: they can see six findings that block keyboard use, separated from thirty that do not.