Confirm the accessibility standard
Identify the WCAG version and conformance level required by your organization or customer. A request for WCAG 2.1 Level AA is different from a request for WCAG 2.2 Level AA. If Section 508 applies, the assessment may also need to cover requirements beyond a web content audit. Share the actual procurement language or accessibility questionnaire so the evaluation is based on the right requirements.
List pages, components, and complete tasks
Provide a sitemap or page list, but also describe what users need to do. Include registration, account access, search, submissions, purchases, and other essential workflows. Identify shared components such as navigation menus and dialogs. Error messages, confirmations, and different user roles can reveal issues that are not visible in a list of URLs.
Arrange authorized test access
Prepare accounts for each role included in the evaluation, with representative content and data. Confirm the test environment and any restrictions on transactions or submissions. Identify third-party tools and who is responsible for them. This prevents delays and helps distinguish findings your team can fix from those that require vendor support.
Agree on the audit report
For a WCAG accessibility audit, ask for findings that identify the affected location, steps to reproduce, user impact, relevant WCAG criterion, and remediation guidance. Confirm which browsers and assistive technology combinations are included. An audit report should state its scope and limitations so readers do not assume untested systems were evaluated.
Plan remediation and verification
Name the developers, designers, and content owners who will review the findings. Reserve time to clarify issues, implement fixes, and retest. A scan alone cannot establish accessibility conformance, and an audit does not correct barriers by itself. Use an accessibility remediation plan to assign owners. The project plan should account for both evaluation and remediation.
Frequently asked questions
Should we audit a staging site or the live website?
Use an environment that represents the experience you need evaluated and permits the agreed tests. Staging can allow transactions and error testing without affecting real users, but it must contain representative content and functionality. Record any differences from production. After deployment, additional checks may be needed for configuration, integrations, or changes that were not present in the evaluated build.
What test accounts should we prepare for an accessibility audit?
Provide authorized accounts for every role included in the scope, with enough representative data to exercise the relevant tasks. An administrator and an ordinary user may encounter different forms, controls, and permissions. Explain multifactor authentication, session limits, and restrictions on submissions or payments. Agree on how to handle test data and account removal before evaluation begins.
Can we audit only our most visited pages?
Traffic can help prioritize work, but it does not identify every important accessibility risk. A less-visited password reset or payment error may determine whether someone can complete an essential task. Include representative templates, components, roles, and complete processes when defining coverage. Our website audit service explains how those factors affect the testing scope.
What should be agreed before audit testing starts?
Confirm the product and build, target standard, included pages and workflows, testing environments, deliverables, and exclusions. Identify the people who will answer product questions and implement changes. Also confirm whether the engagement includes an ACR, a findings review, or retesting. A documented scope helps both teams recognize when a later request requires additional work.