The Material of Teaching · Cross-functional working session
In this article
- The decision: deliver the audit as a workbook the team works in, not a PDF they read once — the format determines whether the findings ever get fixed.
- The method: five sheets that separate what changes (findings, progress) from what doesn’t (evidence, scope), with progress computed, never typed.
- Who does what: the auditor builds and owns the structure; developers, content, design, and stakeholders each work a defined part of it.
- The rule: progress is derived by formula from the status field, so the workbook can’t lie about how far along it is.
A starting point, not a fixed system. If your team works in Jira, Azure DevOps, or Asana, treat the register as the audit and planning layer and export findings into your tracker — keep the systemic layer and dashboard here. Adapt the sheet to your environment; that adaptation is part of the work.
The decision this article is about: an accessibility audit’s value is decided by its format before anyone reads a word of it. A PDF report is read once, summarised in a slide, and then ages while the product keeps changing. A workbook designed as the working surface of the remediation stays current, because the team fixes, verifies, and closes findings inside it. Choosing the workbook over the report is the call that determines whether the audit changes anything.
The situation
A WCAG 2.2 AA audit of a reasonably large site produces hundreds of findings across many pages and several teams. The findings have to be understood, assigned, fixed, retested, and closed — over weeks or months, by developers, content owners, and designers who were not in the room when the audit was run.
That is the real job, and it starts the moment the audit ends. So the question that should govern the deliverable is not “does this present the findings clearly?” It is “can the team work in this — assign, fix, verify, close — without the auditor in the room?” A sixty-page PDF fails that test on contact. A developer cannot filter it, a stakeholder cannot see progress in it, and nobody can record that a finding has been fixed and retested.
The trap
The reflex is to make the audit thorough and readable — and to optimise it for the moment of delivery. That produces three formatting habits that all read well and all fail the team afterwards.
Grouping findings by WCAG success criterion reads well to auditors and to nobody else: a developer doesn’t fix “1.1.1”, they fix a component on a page. Writing findings as prose paragraphs makes them impossible to filter, count, or assign. Expressing severity as adjectives — “significant”, “moderate” — makes them impossible to sort. Each habit serves the handover and works against every day after it.
The lesson worth keeping: a deliverable that is finished when it’s handed over is a deliverable nobody can work in. The audit is the cheap part. The format has to carry the months that follow.
The method: five sheets
A workbook of this kind settles into five sheets. The point is the partition — each sheet answers a different question, changes on a different rhythm, and is read by a different person.
- Findings register — the layer where work happens. One row per issue, never per criterion: where it occurs, what fails, which criterion, severity on a defined scale, the user impact in plain behavioural terms, and a status. Everything must be filterable. The discipline is granularity — “alt text inadequate across product imagery” is a category pretending to be a row. Ten thousand images with one shared failure become a single systemic finding pointing at the cause, plus a small sample that proves the pattern.
- Evidence — screenshots by finding ID, the assistive technology used, reproduction steps. Separated from the register because it’s written once and read rarely — but when it’s read, it’s read under challenge (“is this really a failure?”), so it has to settle the argument on its own.
- Systemic layer — the recurring causes behind clusters of findings, and the rule that prevents each from regenerating. This is what separates an audit of symptoms from an audit of causes: individual findings close one by one, but a systemic failure closes only when its source is fixed.
- Progress — counts and proportions derived entirely by formula from the register’s status field. The moment progress is typed rather than computed, the workbook holds two versions of the truth and the optimistic one wins. This is the sheet stakeholders open; it must never be hand-editable.
- Scope and method — what was tested, with what, on which dates, against which target, and what was excluded. This sheet exists for the reader two years away — possibly a lawyer, possibly you.
Who does what
- Auditor / researcher — builds the workbook, writes the findings at the right granularity, defines the severity scale and the status vocabulary, and owns the structure. The contribution isn’t finding problems; it’s making the remediation legible and trackable for everyone else.
- Developers — work in the findings register: pick up issues by component and page, fix them, move each to “fixed”, and link the change. They never edit the progress sheet — it follows their status changes automatically.
- Content — owns findings on copy, alt text intent, link text, and reading order in content, working the same register rows.
- Design — owns findings on contrast, focus order, target size, and anything that has to be corrected at the component level so it doesn’t recur per instance — i.e. the systemic-layer fixes, not just the instances.
- Stakeholder / programme owner — reads the progress sheet, and asks the one question the status vocabulary exists to answer (below). Doesn’t work in the register; relies on it being honest.
The division only holds if the status field is honest, which is the next point.
The rule that keeps the workbook honest
The single highest-leverage decision is the status field, and it’s a precision problem, not a project-management one. “Done” is fatal, because it flattens at least three different conditions: a fix has been made, a fix has been verified by retest, and a finding has been consciously accepted as a known limitation. The status vocabulary needs a distinct value for each — because the gap between “fixed” and “verified” is exactly where accessibility programmes quietly fail. Changes ship, nobody retests with the assistive technology that surfaced the issue, and the register fills with closures the next audit reopens.
Because progress is computed from this field, the vocabulary is also what stops the workbook lying. If “fixed” and “verified” are the same value, the progress sheet will always look better than the product is.
For a stakeholder, that’s the question to ask in every status meeting: how many findings are verified, not just fixed?
The instrument
This article comes with the audit workbook itself — the five sheets pre-built, with the status vocabulary defined, the progress sheet wired to the register by formula, and the severity scale set. Drop in findings and it tracks itself. Sheet and column headers are written for the whole team, so a developer or content owner can work in it without a walkthrough.