Preparing for an accessibility audit comes down to five things: lock the scope, gather access credentials, freeze the build, brief your team, and set expectations for what the audit report will and will not cover. The auditor evaluates a defined set of pages, screens, or user flows against WCAG 2.1 AA or WCAG 2.2 AA. The cleaner your inputs, the faster the auditor identifies issues and the more useful the report becomes for remediation. Most preparation work takes a few hours spread over a week.
| Step | What it covers |
|---|---|
| Confirm scope | Final list of pages, screens, templates, or user flows the auditor will evaluate. |
| Choose the standard | WCAG 2.1 AA or WCAG 2.2 AA, plus desktop, mobile, or both environments. |
| Gather access | Staging URLs, test accounts, MFA bypass, and any gated content credentials. |
| Freeze the build | No design or code changes to scoped pages during the audit window. |
| Brief the team | Identify a point of contact for questions and confirm the remediation owner. |
Lock the scope before the audit starts
Scope is the single biggest factor in audit accuracy and turnaround. The auditor needs a final list of what to evaluate, whether that is unique page templates on a marketing site, key user flows on a SaaS web app, or specific screens in a mobile app.
Pick representative pages, not every page. A 500 page site does not need 500 pages audited. Templates, key conversion paths, and authenticated areas usually cover the same patterns that repeat across the rest of the site. A well chosen sample will catch the issues that matter.
If you are unsure how to scope, ask the auditor to recommend a sample. An accessibility audit from Accessible.org includes scoping guidance during the quote stage.
Choose the standard and environment
Most audits target WCAG 2.1 AA or WCAG 2.2 AA. WCAG 2.1 AA remains the most widely referenced standard for ADA compliance and procurement. WCAG 2.2 AA is increasingly requested in enterprise contracts and government work.
Confirm whether the audit covers desktop only, mobile only, or both. A responsive marketing site usually warrants both. A native mobile app is its own evaluation. Document any assistive technology pairings the auditor should prioritize, like NVDA on Windows or VoiceOver on iOS.
What credentials and access does the auditor need?
Authenticated content is part of most audits. The auditor needs working test accounts for every role they will evaluate: standard user, admin, guest checkout, and any tier specific views.
Provide credentials at least three business days before the audit start date. Include staging or production URLs (staging is preferred when stable), test account usernames and passwords for each role, MFA bypass instructions or a shared authenticator method, any VPN, IP allowlisting, or geofencing requirements, and sample data for forms, checkout, or search where needed.
Broken credentials are the most common reason audits stall. Verify every login the day before the auditor starts.
Freeze the build during the audit window
The auditor evaluates the site as it exists during the audit window. If your team pushes design or code changes mid audit, the report can reference issues that no longer exist or miss issues introduced after the auditor moved on.
Hold deployments to scoped pages until the report is delivered. If a critical fix must ship, notify the auditor so they can re-check the affected area. This keeps the report accurate and the remediation list clean.
Brief your internal team
Identify one point of contact who can answer questions during the audit. The auditor may need clarification on intended functionality, hidden states, or content that requires specific user actions to surface.
Confirm who owns remediation before the report lands. Developers, designers, and content editors usually share the work. A named owner per area shortens the gap between report delivery and the first fixes going live.
Set expectations for the audit report
The audit report identifies WCAG nonconformance, documents each issue with location and recommended fix, and assigns severity. It does not include source code rewrites or design files. The auditor identifies what is wrong and how to address it. Your team applies the fixes.
Scans and audits are separate activities. Scans only flag approximately 25% of issues and cannot determine WCAG conformance. A manual expert audit is the only way to assess conformance against the standard. If you have conducted a scan beforehand, share the output with the auditor as context, not as a replacement for the audit itself.
Should you conduct a scan before the audit?
A scan can catch surface level issues like missing alt text or low contrast before the auditor begins, which means the audit report focuses on deeper, harder to detect issues. This is optional and most useful for teams with development capacity to address easy wins quickly.
Do not treat a clean scan as readiness for an audit. The two evaluate different things.
Frequently asked questions
How far in advance should I prepare for an audit?
One to two weeks is typical for most projects. Larger scopes with multiple authenticated roles or mobile and desktop coverage benefit from three weeks of lead time, mostly to confirm credentials and finalize scope.
Do I need to fix obvious issues before the audit?
No. The auditor will identify issues regardless. Some teams clean up obvious items first to reduce noise in the report, but it is not required. A pre-audit cleanup is a preference, not a prerequisite.
Can I add pages to the scope after the audit starts?
Adding pages mid audit usually changes the quote and timeline. Confirm scope in writing before work begins. If new pages need coverage later, they can be added as a follow up engagement.
What if my staging environment is unstable?
Audit production if staging is not reliable. The auditor needs a consistent environment to evaluate against. Switching mid audit creates inconsistencies in the report.
Who should be the point of contact during the audit?
Someone who knows the product well and can respond within a business day. A product manager, lead developer, or accessibility owner works best. Avoid routing questions through multiple layers, since that slows the auditor down.
Good preparation makes the audit faster and the remediation work clearer. The time you spend confirming scope and access pays back in a report your team can act on immediately.
Contact Accessible.org to scope your audit and get a quote.
