How to audit and create a report on digital accessibility. Part two

In the first article of this series, we discussed why it’s important to verify the state of digital accessibility. We identified the need to highlight the barriers that users, especially those with disabilities, might face on our website, service, or mobile app. Now that we know why we’re doing this, let’s think about the next step: creating the audit report.

How to prepare for an audit?

At first glance, this seems like a simple question, but when we look closer, the answer isn’t so straightforward. One might say: *”It’s easy!”* Just open a report template and start listing the issues you find. Every mismatch with the WCAG (Web Content Accessibility Guidelines) needs to be reported and fixed immediately. But here comes the first important question: Can every issue be fixed in a way that doesn’t create new problems for a different group of users?

Sometimes, we need to offer more than one solution. Depending on the context, developers, designers, or content editors might fix the issue in different ways. The key word here is *context*. Even during preparation, we need to understand who the audit is for. For that, we need to think (or ask stakeholders) about:

The business processes
The target audience of the digital product
The desired level of accessibility

Is that all for preparation?

No, of course not. Now it’s time to set up the environment for testing accessibility. Besides the audit report template, you’ll need to choose the right tools for accessibility testing. In our team at Kinaole, everyone uses different tools, but there are some that we all rely on. These include browser extensions and external apps, such as:

HeadingsMap – an extension to check the structure of headings
Landmark Navigation via Keyboard or Pop-up – identifies landmarks
Colour Contrast Analyser – an app for checking color contrast

We also use simulators for visual impairments, tools to check the tab order, and bookmarklets that modify the HTML code of a webpage.

What does a digital accessibility audit involve?

Now that we know why we’re doing the audit and have set up the testing environment, it’s time to start the actual audit. Depending on the needs, time, and budget, the analysis may include up to four stages. Each stage helps identify barriers and obstacles users might face.

The quickest assessment is done through **automated tests** using publicly available tools. These include browser extensions that help identify some issues. The most common ones are:

axe DevTools
ARC Toolkit
Lighthouse
ANDI

These tools give a quick overview of where to focus for deeper manual testing. However, automated tools can’t catch everything. That’s why it’s a great starting point for the **manual analysis**, also known as the expert method, where WCAG criteria are manually checked based on specific techniques. We’ve covered many of these in our **WCAG Academy** series.

During this stage, we can also use assistive technologies like screen readers (e.g., NVDA, VoiceOver, JAWS). This helps us better understand users who rely on these tools. We cover this and more in one of our training sessions, which also touches on a broader topic: testing with **users with disabilities**. Whenever possible, we try to include at least one person who is blind, Deaf, uses only a keyboard, or has cognitive disabilities (including neurodiverse users). This helps us find real barriers users may face.

Summary

Today, we answered two questions: how to prepare for an audit and how to conduct one. We prepare by understanding the needs and possibilities, and then break the audit down into four main parts: