How do you conduct a WCAG audit to assess the accessibility of a web page or site?

Unless you're in Canada a decade ago (you are not), do not worry about A vs AA. In practice, both lawsuits and government offices will always check for WCAG A and AA. Test for both and prioritize based on user impact. Consider AAA for internal best practices - some good ideas in there.

Companies, educational institutions, government agencies, and accessibility laws and regulations use WCAG level AA. In the vast majority of cases, you should too. The WCAG conformance levels are cumulative, so level AA includes all the requirements (success criteria) from levels A and AA.

Level AA is the minimum legal requirement for compliance and consists of all the success criteria under both Level A and AA (it works cumulatively). Level AA tries to strike the balance between attainable for every organisation while serving a wide group of users. It's important to remember that a Level AA conformant website does not equal a fully accessible website. there will still be barriers for people (even at Level AAA) because the WCAG doesn't account for every type of disability. Neurodiversity, for example, is currently very underrepresented because these needs differ very much person to person and can't really be caught in strict pass/fail success criteria. That's why user research remains very indispensable.

Choosing the right WCAG tool is extremely important for a good audit. These tools check your web content for accessibility issues based on WCAG rules. There are many options like TPGI, Evinced, WAVE, AChecker and MAUVEE++. Some are online tools with licenses and others are plugins that can be installed on browsers, even free ones. It's crucial to think about things like how easy it is to use, how accurate it is, whether it works with your system, and what features it has. Choosing a tool that suits your needs can streamline the audit process and help you quickly resolve any issues.

The best tools are the ones which people actually use in daily life. A range of software that tests functionality by users, for example different speech softwares, text/transcript/captioning tools, etc will give practical insights rather than generated guidance. Of course, testing can be done with both WCAG tools and user software.

Don't just rely on tools to perform your WCAG test because the most parts of WCAG cannot be tested for automatically and need human evaluation. To get a good assessment, you require in-depth WCAG knowledge to manually assess each success criterion. It's worth the investment to have a specialist conduct this, as they should also give you good quality solutions for the issues they report. Please keep in mind that a WCAG assessment doesn't mean there aren't other accessibility barriers on your site, either. Try to conduct user research with disabled people to gain further insights into increasing accessibility beyond WCAG conformance and creating a better product for everyone.

From my experience, I have found tools like WAVE, Accessibility insights, Lighthouse (a Chrome dev tool) and Color contrast analyzer really helpful in performing WCAG test.

Some WCAG tools are also available as browser extensions in modern browsers. Instead of having to go to an online tool, you install the browser extension, open developer tools, and then run the WCAG test right from developer tools. You can run the test on part or all of the web page you are currently viewing and see results as described above for the online tools.

Having worked with thousands of organizations on building out and scaling an accessibility plan for their websites or mobile applications, I would stress going beyond "WCAG Tools" to perform an audit. Automated testing tools are critical to scaling and maintaining accessibility long-term, specifically for content management teams and when used properly in development life cycles. However, they do not replace the need for human-led testing and usability feedback from people with disabilities. If tools-alone are used, without any internal or external accessibility engineers perform testing with assistive technology such as screen-readers (preferably from a native user), most digital properties will be far from compliant or usable.

One simple, but effective, way of using assistive technology to manually check a website is to use the screenreader built right into your operating system. (On Mac, it is called VoiceOver. On Windows, it is called Narrator.) Do some internet searching to find out how to use these tools and your manual testing will be forever changed. They allow you to experience a website much like those that use an expensive screenreader would. The tools catch issues and verify repairs in ways that little else can!

The human element is key here. To review only what software has provided is to miss major pieces of the accessibility puzzle. WCAG is guidance; user experience is what shapes the review into something that has meaning and impact.

After understanding where to improve the accessibility of your product, website or software you should implement changes continuously and always bring a value perception to your users. In small companies or products that are just starting out on the market, you will face resistance when dedicating time to improving the level of accessibility. But always keep the Curb-Cut Effect in mind. By improving the product's accessibility you will improve your product as a whole. Make changes gradually, and look for evidence through user and usability testing that your product is actually improving. This will make your stakeholders realize the value of a product built with accessibility.

See w3.org's Template for Accessibility Evaluation Reports as a helpful starting point. Creating a standardized format ensures consistency. This should detail each issue and Incorporate an action plan with the next steps.

Beyond WCAG audits, consider accessibility throughout development. Engage users with disabilities for feedback and continuously monitor for ongoing accessibility. Train your team on best practices and prioritize inclusive design. Incorporate user feedback mechanisms and diversify your audit tools. True accessibility goes beyond mere compliance.

The steps described in this article don't constitute an accessibility audit (or, as it's called here, a "WCAG audit"). These steps describe a quick test using an automated accessibility testing tool. While these tools are very useful, they generally catch fewer than half of accessibility problems. A full audit includes manual testing by someone knowledgeable about WCAG, covers 100% of WCAG (using the particular version and conformance level you choose -- A, AA, or AAA), and will find many more issues than a quick test with automated accessibility tools.

Web accessibility should not be relegated to a secondary consideration; rather, it must be prioritized as a fundamental step to ensure inclusion for all.

We must also consider the apps that have rules similar to the web but not the same. In fact we talk about MCAG compared to WCAG, to allow a more specific approach in the mobile sector.

After reading this, I would stress the need for user feedback and manual testing. This article really focuses on automated testing, which most organizations should not consider an 'audit' of their website, let alone a mobile app or complex web application. Tools are fantastic and getting better every day, but they are only as good as the user's experience and understand of the WCAG Success Criteria and accessible design or development. Most individuals running tools are not accessibility engineers, so the results will have quite limited impact or even be overwhelming. Live-user testing from people with disabilities in tandem to running automated testing tools is the only true path to not just compliance, but creating highly usable products.