Turn an accessibility audit into a remediation brief and retest plan

Preserve the audit baseline

An audit report becomes useful operationally when the delivery team can connect each finding to a specific interface and reproduce the problem. Keep the original report unchanged. Record the tested product version, pages or journeys, environments, WCAG version and conformance level, exclusions and any limitations. W3C’s reporting guidance makes scope and method central to interpreting findings.

Do not quietly replace the original evidence when the product changes. Link subsequent work to it. If the report covers an earlier release, ask which findings remain reproducible and which require clarification. An issue that cannot be reproduced should be marked for investigation, not automatically closed.

Write tickets around the barrier

A useful remediation ticket describes the affected task, the behaviour observed and the result a person needs. Include the report reference and relevant success criterion where supplied. Retain the evaluator’s evidence, but ask for clarification when a suggested fix is ambiguous or assumes a technology the product does not use.

Separate the user-facing outcome from the implementation proposal. A developer may identify a better way to achieve the same accessible behaviour. Agree the acceptance checks before implementation so a completed code change is not mistaken for a verified fix.

• Issue ID and original audit reference.
• Affected page, component and interaction state.
• Reproduction steps and the test environment used.
• Observed barrier and expected accessible behaviour.
• Responsible owner, dependencies and planned release.
• Acceptance checks, retest evidence and remaining uncertainty.

Prioritise without losing the small findings

Use a working priority discussion that considers blocked tasks, effect on people, reach across the product and implementation dependencies. A defect in a shared component may affect many pages; one report entry can therefore represent substantial work. Conversely, repeated findings may share one underlying cause. Link them rather than losing their individual evidence.

Agree who can approve deferral and what interim help is genuinely available. Explain any workaround in plain language and check that people can actually use it. A support channel may help while a repair is underway, but its existence is not proof that the digital journey meets the chosen standard. Keep unresolved barriers visible in release decisions.

Make the remediation brief operational

Name the product owner, implementation lead and retest contact. Specify what the delivery includes: component changes, content updates, design decisions, supplier dependencies and release verification. Ask the team to identify work it cannot control, such as an embedded service, rather than silently excluding it.

Use a shared issue register with distinct states such as awaiting clarification, ready for work, implemented, awaiting retest, verified and unresolved. These labels are an editorial workflow suggestion, not a W3C requirement. Require a short reason when an issue moves backwards or is deferred. This makes the remaining work understandable without relying on an overall percentage.

Define the retest before the fix ships

For each issue, agree which original checks will be repeated and which related states could be affected. Retest the relevant journey, not just a screenshot or an isolated component. Include appropriate human evaluation: W3C states that tools alone cannot determine whether a site meets accessibility standards. Record the tested build and environment with the outcome.

A narrow fix verification and a broader conformance evaluation answer different questions. Decide which you are commissioning. If the scope expands, document the additional pages, states and methods. Do not describe successful checks on a few repaired components as a whole-site compliance result.

Hypothetical example: repairing a booking dialogue

An audit identifies that keyboard users cannot reliably return to their starting point after closing a booking dialogue. The ticket records the original steps and links the affected shared component to the booking journey. The team agrees to check opening, interaction, cancellation and successful completion, including the appropriate focus behaviour in each state.

After implementation, the retester repeats the original steps and checks another page using the same component. One path works but cancellation still behaves incorrectly. The issue remains open with updated evidence. This invented example shows why a component change and a verified user journey are separate milestones.

Leave a maintainable record

At handover, request the issue register, retest results, unresolved items and a concise account of what was and was not evaluated. Feed relevant checks into future design, content and release work. W3C recommends evaluation throughout development, rather than only at the end.

Keep any public accessibility statement aligned with the evidence and known limitations. The directory can help locate services, but a listing does not establish that a provider can implement your platform’s fixes or independently verify them. Ask about those capabilities against this brief.