Audit Readiness
WCAG 2.2 AA Audit Readiness: What to Prepare Before Review
A practical readiness guide for teams preparing websites, apps, and critical journeys for a WCAG 2.2 AA accessibility audit.
Start with journeys that carry risk
A useful audit scope starts with what users need to complete. For regulated or high-trust products, this usually includes sign-in, onboarding, search, account management, payments, forms, dashboards, document access, and support flows.
Page count helps estimate effort, but it does not explain risk. A small authenticated workflow can need deeper testing than a larger group of static pages.
Prepare access before the audit begins
Auditors need stable access, representative data, known constraints, and the standards that matter to your organization. Preparing these inputs early reduces delay and makes the final report easier to defend.
- Test credentials for each role in scope.
- Representative sample records, transactions, forms, and documents.
- Browser, device, and assistive technology expectations.
- Applicable standards such as WCAG 2.2 AA, IS 17802, GIGW, Section 508, or EN 301 549.
- Known exceptions, upcoming redesigns, and release constraints.
Make ownership clear
Accessibility findings often cross team boundaries. A keyboard trap may need engineering work, but the expected behavior may need product and design approval. A missing document structure may sit with content, legal, or operations.
Before the audit starts, identify who will review findings, who can approve priority decisions, and who will convert issues into delivery work.
Define what a useful report must include
The report should be useful to both governance and delivery teams. Ask for evidence, severity, affected journeys, standards mapping, remediation guidance, and retest expectations. Without that structure, findings become hard to prioritize and harder to close.