A useful guide does not promise certainty. It gives you better questions, a shared vocabulary and a clear place to start.
Group by component
Convert a list of two hundred page issues into eight or nine component causes. Fix the component, fix every page.
Test what tools miss
Keyboard-only paths, focus management in dialogs, screen-reader announcements and comprehensible error messages.
Prioritise by user impact
Rank findings by whether they block a task, not by how quickly they can be closed.
Hold the line
Axe checks in CI plus a published accessibility statement, so conformance does not decay between audits.
Group findings by component, not by page. Two hundred page-level issues are usually eight or nine component causes, and that difference is what makes remediation finishable.
- Buttons and links: correct element, discernible name, visible focus
- Form fields: persistent labels, described errors, sensible grouping
- Dialogs and drawers: focus moved in, trapped, then returned
- Menus and disclosure: real buttons carrying aria-expanded
- Tables: captions and scoped headers, no layout tables
- Media: meaningful alt text, captions, nothing autoplaying
- Colour pairs checked as design tokens rather than per screen
- Headings: one h1, no skipped levels, structure before style
- Every key journey completed with the keyboard alone
- One journey listened to end to end with a screen reader
- Reading order matches visual order
- Automated checks failing the build rather than warning
- Accessibility statement published with a contact route
- A named owner for incoming accessibility reports
14 items · no email required
Where teams go wrong with this
Four failure patterns we have watched play out often enough to name. None of them is caused by a lack of effort; all of them are caused by sequencing.
Trusting the automated scan
Automated tools catch roughly a third of real issues and almost none of the ones that block a task. Keyboard paths, focus management and screen-reader announcement have to be checked by a person.
Fixing pages instead of components
Two hundred page-level findings are usually eight or nine component causes. Fix the component and every page inherits it; fix the pages and you will be back next quarter.
Prioritising by effort
Closing the quick ones first produces a shorter list and an unchanged experience. Rank by whether the issue blocks a task, then by how many people meet it.
No guard after remediation
Without automated checks failing the build and a named owner for incoming reports, conformance decays release by release until the next audit finds the same things.
Questions this guide raises
It depends on your market and sector, but it is the practical standard almost everywhere we work: ADA exposure in the US, the public-sector regulations in the UK, AODA in Ontario and DDA expectations in Australia all converge on it. Treating it as a build requirement is cheaper than treating it as a risk.
Far less than people expect when it is grouped by component, and far more when it is retrofitted screen by screen after launch. The expensive version is the one where nobody looked until a complaint arrived.
If you are a public-sector body in the UK, yes. Everyone else benefits from one anyway: it documents your conformance level, names the known gaps and gives people a route to report problems, which is the difference between a gap and a grievance.
- Website Redesign Planning GuideThe questions to settle before design starts.
- App Launch Readiness ChecklistA practical worksheet for the fortnight before you submit to the stores.
- E-commerce Migration ChecklistHow to replatform without losing orders, URLs or rankings.