The audit is not the work

We have inherited a lot of accessibility audits. Most are technically correct, several hundred items long, sorted by WCAG success criterion, and completely inert. Nobody knows where to start, so nobody starts.

Sort by consequence, not by criterion

A missing alt attribute on a decorative image and an unlabelled payment confirmation are both AA failures. They are not remotely the same problem. The first is a defect; the second is a person who cannot use their bank. Re-sorting an audit by what it blocks turns a wall of 340 issues into a programme of about sixty.

Give every issue an owner and a home

Most findings are not one-off bugs — they are one component repeated across forty screens. Fix them where they live. Half of a typical audit collapses into a handful of shared component changes, which is also the only way the fix survives the next feature.

• Re-score findings by task impact before touching any code
• Group by component, not by page
• Fix in the design system so the fix propagates
• Add a regression gate the same day you close the issue

Automate the boring 40%

Automated tooling catches perhaps 40% of real accessibility issues. That is not a reason to skip it — it is a reason to automate exactly that 40% so your human testing time goes to the part machines cannot check: focus order, announcement quality and whether the flow actually makes sense when you cannot see it.

The report is a starting position. The work is what you change about how you ship.