How to Prepare a Website for a Web Accessibility Audit

In our previous blog posts, we covered what a web accessibility audit is, who needs it, and when to conduct one.

In particular, you can read What Is a Website Accessibility Audit and Who Needs a Web Accessibility Audit.

In this article, we will discuss how to prepare for an accessibility audit so that it is as effective and useful as possible.

Why Prepare a Website for an Audit

Why should you prepare for a web accessibility audit at all?

In fact, it is possible to check whether a website follows accessibility principles without any preparation. However, proper preparation can make the audit more useful and lead to better results.

In particular, preparation helps:

• speed up the audit process
• obtain more accurate results
• avoid missing important user journey stages and ensure they are tested

When we talk about preparation, we do not mean fixing potential accessibility issues in advance or performing accessibility testing on your own.

Preparing a website for an audit means analyzing key user scenarios and defining the audit scope.

Defining the Scope of a Website Accessibility Audit

Compliance with WCAG requirements is a fundamental part of web accessibility. However, it is equally important that users can successfully complete the main user flows and use the website’s functionality.

Most websites have a standard user journey. For example, making a purchase in an online store (from selecting a product to completing payment) or submitting a request for a service (filling out a contact form).

Therefore, when preparing for a website accessibility audit, it is worth documenting the most important user scenarios and using them to define the list of pages and components to be tested.

It is also important to decide whether the mobile version of the website should be tested, as this is usually considered a separate audit option.

Before starting an accessibility audit, it is useful to understand the following:

• what the main user scenarios are
• which pages should be tested
• whether complex elements should be tested (forms, modals, dashboards)
• whether the mobile version of the website also requires an accessibility audit

This makes it much easier to estimate the scope of work and avoid missing important scenarios.

Preparing a List of Key Pages and User Flows

An accessibility auditor does not always know your product well. On the one hand, having your website reviewed by an external specialist is also a good UX test. On the other hand, to receive a high-quality accessibility audit, it is worth documenting the main user steps in standard scenarios in advance so the accessibility consultant can better understand your website.

This will also help create a detailed list of pages for the audit.

Typically, the homepage is the first page users visit, which is why auditing its accessibility is usually an essential part of the review. However, there are situations where traffic is directed to a specific product or service page and users immediately proceed to checkout. In such cases, the homepage may receive less attention from visitors. As a result, auditing the homepage accessibility may have lower priority compared to auditing a product page.

Typical pages included in an accessibility audit are:

• homepage
• product page
• shopping cart
• checkout form page
• payment page
• user account
• login or registration page
• search results page

This set of pages will vary depending on your product’s domain.

Typical elements to check for accessibility include:

• navigation
• search form
• user input forms
• dropdowns and menus
• charts or data visualizations
• image galleries
• video player
• modal windows and popups

Preparing Access Credentials (If Needed)

A website may have multiple user roles. If pages or components unavailable to unauthenticated users need to be tested, test accounts should be prepared for the accessibility auditor. This is another important detail that is easy to forget and may delay the audit process if it becomes clear during the audit that some scenarios or website sections are inaccessible. Without proper access, some issues may remain undiscovered.

In addition, a website accessibility audit may take place at different stages of product development. If the accessibility review is planned before release and the website is not yet public, the external accessibility specialist will also need access to the testing environment. Providing such access for an external consultant may take time and require approval from multiple departments, so it is worth considering this in advance.

Checking Website Accessibility with Automated Tools

Before an accessibility audit, the team may choose to check the website using automated tools (for example, Lighthouse or axe). This is optional because such testing is already part of the audit process.

However, there is an important detail to keep in mind. An automated report may show that a website is fully or almost fully accessible, which can create the impression that a further audit is unnecessary. This can be misleading because automated accessibility testing tools are unable to detect all issues or test all scenarios and ways users interact with a website. Manual accessibility testing remains an essential part of the audit process for most websites.

You can read more about why automated testing alone is not enough in our article Automated vs Manual Accessibility Testing: What’s the Difference.

Collecting Information About Known Issues

Before the audit, it’s highly useful to gather info on already known issues.

For example, there may already be user complaints related to UX problems or website usability issues. It is worth reviewing user feedback for indications of accessibility problems.

The team may also already know about certain problematic scenarios. If such scenarios exist, they should be shared before the website review begins.

If the development or product team suspects accessibility violations in specific components or pages, these should also be added to the list.

Before an accessibility audit, it is useful to document:

• user complaints about accessibility or usability issues
• problematic user scenarios
• a list of complex components
• potential accessibility violations identified by the team

This preparation helps focus additional attention on problematic and critical areas.

Preparing the Team for Audit Results

This is a highly important step, yet easy to miss. Accessibility audits performed by external specialists are often treated like an exam. However, the purpose of an accessibility audit is primarily to improve the user experience rather than evaluate the development team.

It is important to understand that accessibility issues are almost always discovered during an audit, even on websites that pay significant attention to accessibility. Even very high-quality websites still have room for improvement.

Therefore, teams ordering an audit should treat accessibility testing as support rather than criticism. An audit helps uncover hidden issues, create a plan for future improvements, and prioritize tasks.

So it is worth remembering that the goal of an audit is not to “pass a test”, but to understand the current state of the website’s accessibility.

What NOT to Do Before an Audit

To ensure that a website accessibility audit reflects the real state of the website rather than a demo version, you should NOT:

• make rushed code changes only to pass the audit
• add ARIA attributes to every element in an attempt to make the website more accessible
• rely solely on automated accessibility testing results
• hide pages or scenarios that are considered problematic

Proper preparation helps make an accessibility audit more effective and useful.

If you are planning a web accessibility audit, this preparation checklist can help you achieve a more practical and valuable result.

Checklist Before a Web Accessibility Audit

Before starting an audit, it is useful to prepare answers to the following questions:

• Which pages or user flows are the most important for the business?
• Should the testing cover the staging environment, production version, or both?
• Are test accounts or access to restricted sections required?
• Are there complex interactive components (modals, dropdowns, widgets)?
• Is there a separate mobile version or separate mobile-specific user scenarios?
• Does the website use third-party widgets or integrations?
• Have there been previous user complaints related to accessibility?
• Are there pages or features the team already considers problematic?
• Is there a deadline or a specific reason for conducting the audit (release, redesign, launch preparation, etc.)?