There is no one right way to do an accessibility audit. On this page, I share my own views on the subject.
I've so far been doing accessibility audits in a team setting. I like having teammates with who I can analyze the results together. We can also share the workload, which can make a difference when another project is going on at the same time. Having someone to audit with can be great especially when you are doing your first audits.
The audit is not usually done on the whole site. There can be a lot of content on a site, and analyzing every single page would be expensive. Most of the audits I've been a part of consisted of 10-20 pages of content. The pages were selected to represent the various kinds of content on the site. When selecting the pages to audit, here are some things to get into the audit, if they are present on the site:
There are a lot of tools for both automated and manual auditing. I have listed some on the Testing for accessibility page. I recommend testing some of the tools to get a feel of what you prefer to use. Many tools do pretty much the same thing, but the user interfaces are different. Also, the way of reporting the results can vary.
Use any automated tools you may have access to. This will save you some time and you can focus on the manual testing. There are a lot of paid options, as well as free ones.
The automated tools also can create some false positives. And some tools might straight away even suggest things for you to check. There are also manual tools to help with accessibility auditing. They usually analyze a single page.
The automated and manual tools cannot find all possible accessibility issues. There are many things that I find good to test yourself:
When there is the possibility of using automated tools, it is usually a good idea to start with them. This will give you some idea of the state of accessibility of the site you are working on, right from the start.
If you use several tools, they often report the same problems. So don't get concerned if you get a lot of findings, some of them will most likely be duplicates.
There are likely as many ways to do the audit as there are people doing the auditing. No method is automatically better or more effective. The best way to audit is the one that feels the most natural and efficient to you.
I usually like to go either page by page or tool by tool. It depends on the project at hand. Some people also like to go by the WCAG criteria.
My working style also changes depending on if I work alone or in a team. When working alone, you can do exactly what you want to do. When working in a team, it's worth deciding together with the team to work out the appropriate working methods and division of labor. In a team, you can easily divide up the work based on tools or criteria. For example, if there is a person who is fluent in screen readers, it might make sense to use their skills instead of having someone learn how to use a screen reader while auditing.
I usually like to collect all findings in a separate document. I like to sort the findings into global versus per-page lists. That way I can see the issues that are happening around the whole site, and can make sure the client knows that those issues should be handled with higher priority.
Website Accessibility Conformance Evaluation Methodology (WCAG-EM) is an approach for determining how well a website conforms to Web Content Accessibility Guidelines. This might be a good solution for you if you don't yet have your own way of doing things. They also offer the WCAG-EM Report Tool: Website Accessibility Evaluation Report Generator, which helps you follow the steps of the WCAG-EM and generate a report from the input you provide.
A report is usually created to gather all the findings in a single place. There are many ways to create such a report. Here are some ways you can organize a report:
The most important thing is to give honest results of the findings. It is often useful to provide a list of findings sorted by WCAG criteria. If you can, differentiate the issues between content issues and technical issues. If you can separate also the visual problems, even better. This will make it easier for people to get the issues fixed.
I like to provide my clients with as comprehensive solutions as possible to the issues I find. I will usually not offer complete coding solutions unless agreed upon beforehand. But I will do my best to point the solutions in the right direction.
I strongly recommend a walk-through meeting with the client. The client is unlikely to be an accessibility expert, so the report may feel long, awkward, and daunting. The walk-through meeting also allows you to finalize the project together with the client, which I've liked at least so far.
When you are presenting the findings to a client, try to present them in a positive way. Try to remind the client that most of the issues found are usually relatively easy to fix. If there are things that are handled well on the site, do mention that to them as well. We never give enough positive feedback. The point of an accessibility audit is not to make the client feel bad about the issues they might have but to give them guidance on what should be improved. It's also always good to remember that websites are built by people. And people can make mistakes even if they try to make fully accessible content.