AXS AUDIT GUIDE
WCAG 2.2 Audit Checklist
A WCAG 2.2 audit checks whether a website or digital service meets recognised accessibility success criteria. The aim is not just to pass a checklist. It is to reduce barriers for people using different devices, browsers, assistive technologies and ways of processing information.
This guide gives a practical structure for checking WCAG 2.2, collecting evidence and deciding what to fix first. It also explains where AXS Audit and manual accessibility audits can support the work.
Perceivable
Check text alternatives, captions, adaptable content, contrast and whether information is available in more than one way.
Operable
Check keyboard access, focus order, visible focus, timing, navigation and pointer interactions.
Understandable and robust
Check clear language, predictable journeys, error support, valid code and compatibility with assistive technology.
Checklist
Core WCAG 2.2 areas to review
A useful WCAG 2.2 audit should group issues clearly so teams understand what each problem affects. Grouping findings by principle, component and user impact is usually easier to act on than a flat list of errors.
The audit should also include evidence. For each issue, teams need to know where it appears, why it matters, how serious it is and what a good fix looks like.
AXS Audit supports this by combining scan results with prioritised remediation guidance so teams can move from finding issues to fixing them.
Read our comprehensive guide to WCAG 2.2.
- Perceivable: alt text, headings, labels, captions, contrast and adaptable layouts.
- Operable: keyboard access, focus visibility, navigation order, timing and pointer targets.
- Understandable: clear instructions, predictable behaviour, readable content and helpful errors.
- Robust: valid structure, accessible names, ARIA use and compatibility with assistive technology.
- WCAG 2.2 additions: focus appearance, dragging alternatives, target size and consistent help where relevant.
Evidence
What evidence should an audit include?
A checklist is only useful if it gives teams enough information to act. Good audit evidence should include the affected page, the component or journey, the relevant criterion, the user impact and a practical recommendation.
For repeated issues, teams should also know whether the problem comes from a template, design system or content pattern. Fixing the pattern can reduce barriers across the whole site.
When evidence is unclear or the user impact depends on context, manual review can help confirm the priority and the best fix.
| Audit evidence | Why it helps |
|---|---|
| Affected page or template | Shows where the issue appears and whether it repeats. |
| User impact | Explains who may be affected and what task becomes harder. |
| Recommended fix | Gives developers or content teams a clear next step. |
| Priority | Helps teams focus on the changes that matter most first. |
Beyond compliance
Do not stop at the checklist
WCAG is essential, but a good audit should also consider cognitive accessibility, readability, real user journeys and whether people can complete tasks without unnecessary effort.
This is why a combined approach works well. Automated scanning can find repeated technical problems. Manual review can assess context, journey quality and real-world usability. The Cognitive Accessibility Guide can help teams add this wider layer.
Accessibility audit support
Need help with WCAG 2.2 audit checklist?
AXS Audit can help you identify and prioritise accessibility issues. Calling All Minds can also support manual audit review when judgement, user journeys or stakeholder evidence need deeper attention. Run a free scan now.
Questions people often ask
No. WCAG 2.2 is a core standard, but a full audit should also consider user journeys, cognitive load, content clarity and practical remediation.
Yes. AXS Audit supports WCAG scanning, issue prioritisation and remediation guidance.
Manual testing is recommended for important journeys, complex components and issues that need human judgement.