Website Accessibility Audit : What You Should Know [9 Questions Answered]

Web accessibility audit is the process of evaluating or analyzing your website to determine its accessible state. It is simply knowing your website is not accessible and identifying barriers that are preventing individuals with various forms of disabilities from accessing the site.

The audit here merely is checking if your website complies with the requirements of particular laws and regulations that govern the country your organization operates. In most cases, web accessibility (a11y) audit evaluates your website against the international standard, the Web Content Accessibility Guidelines (WCAG) 2.0/2.1  A/AA standards. Hence, it can be called conformance evaluations as it identifies violations and summarizes your site’s level of compliance with WCAG and other federal rules. An audit report declares the result of such analysis or evaluation and provides a comprehensive, page-by-page analysis with documentation of areas in need of remediation.

Check out our Accessibility Test Tools review 🏆

Let’s answer all the questions you may have one at a time.

Accessibility audit is the starting point of having accessible digital assets. It is done to identify how well accessible or not-so-accessible your site is to a wide range of potential web users and to provide guidance on eliminating the issues to improve customer experience. It could be done reactively or proactively since the benefits of providing disabled access cannot be overemphasized and the failure to provide an accessible digital experience to people with disabilities could be fatal. Among these reasons are to mitigate the risk of a lawsuit which is almost unavoidable in the U.S these days. Other reasons include compliance with regulatory laws and avoidance of subjective fines (such as AODA), business reasons such as the increase in audience, enhancement of brand reputation, and having the edge over the competition. Audits can also be performed to facilitate the decision of either to totally overhaul a site or fix non-accessible elements of the website depending on the available tools and resources.

Digital accessibility laws and their standards vary from one country to another so the requirement to follow depends on the location of your organization and the audience. The United States mandate digital interface (website, applications, documents, etc) are accessible to everyone through the Section 508 requirement, while German organizations are to make their website accessible through BITV 2.0. Italian organizations must be compliant with the Stanca Act, while EU countries are to abide by EN 301 549 for accessible digital interfaces. However, the majority of countries around the world have referenced and mandated the adoption of the international standard, World Wide Web (W3C’s) WCAG 2.0 AA or WCAG 2.1 AA, and hence, serve as the standard to achieve in the U.S.A, U.K, Canada, and all the EU member countries. The WCAG 2.0/2.1 AA standard has clearly defined over 38 success criteria to remove barriers for the major disability types – hearing, visual, motor, speech, and cognitive impairments.

Accessibility audits can be performed at any point during the project, i.e, early on during planning, design, development, or testing. Accessibility testing should be done before deployment and before the publishing of content.  

Side note: Accessibility testing is effective and efficient when taken to be part of standard development and QA practices. 

Because accessibility audit is complex, the evaluation is usually carried out by a11y experts with a proven methodology. The audit can either be carried out in-house by your team or be outsourced to external consultants if the practice is new to your organization. Making use of the automated testing tools and DIY could be problematic if you are not well-grounded at this but experts do know the false positives to ignore from certain reports by these testing tools. Accessibility is a journey, and your audit won’t be a one-time thing, this is where web accessibility solution providers come in handy.

Your digital accessibility audit can be entirely manual or, in most cases, the use of automated tools to assist the manual audit. This is is the most comprehensive and recommended. 

Automated testing or audit is the starting point for your audit. It is performed by scanning your website with an automated accessibility testing tool against the WCAG 2.0 AA, Section 508, BITV 2.0, or any technical standard. A good example of such is the 🔍 Lighthouse accessibility, a tool that provides a report on possible issues and non-compliant certain code conditions. Automated testing tools quickly identify major problem areas and give a synopsis of where deeper issues exist. As good as these sounds, automated testing tools hardly tests the DOM and cannot provide an in-depth analysis you need to be compliant. As a matter of fact, most can only test between 25- 40% of your accessibility issues. This is where the experts and manual testers come in. They conduct page-by-page tests, click-throughs, and review your web content with assistive technologies such as screen readers and keyboard-only commands. So whatever you do, ensure your website is checked by “humans” who provides a human element in web accessibility testing for ADA compliance and provides a comprehensive assessment of your web pages.

The scope of your accessibility evaluation will largely affect the timeline to identify barriers to accessibility, which depends on the reason behind your accessibility (reactive or proactive). Manual testing is time-consuming and takes the bulk of your audit duration while automated testing tools can get the job done in real-time. On average, a comprehensive audit should take around three to six weeks.

The definition of scope before carrying out an a11y audit has a direct impact on the resources available for the audit, hence, its importance. The audit may include device compatibility, browser compatibility, usability testing, and content testing, checking keyboard access, color contrast checking, evaluating the underlying code, etc.

In ensuring your site, pages, and applications are accessible to the disabled, it is important to understand how your users access the website. The devices, the browsers used to access it, and assistive technologies used by these users to navigate the web pages. The combination of these will be your testing platform.

• Devices: You can test your website on a laptop, tablet, phone, watch, etc, and their operating systems.
• Browsers: You can test your website’s accessibility through browsers such as Chrome, Safari, Firefox, etc.
• Assistive Technology: While there are various assistive technologies your users may use to access your site depending on the disability, audits are commonly performed with screen readers such as JAWS, ChromeVox, NVDA, VoiceOver, Talkback, etc.  

The effective combination of these channels to determine your test platform is highly dependent on the available resources. It also plays a role in the discoverability of your website’s a11y issues. 

Side note: Screen readers pairs best with a specific browser. Below are a few combinations of test platforms when performing web accessibility tests:

Desktop test: 

• Computer running on Window OS + NVDA screen reader + Firefox
• Mac OS + VoiceOver + Safari
• Windows OS + JAWS + Chrome

Mobile Phone Test:

• Android + Talkback + Chrome
• iOs + VoiceOver + Safari 

Tablet Test:

• Android + Talkback + Chrome
• iOs + VoiceOver + Safari 

Your audit can involve every page/screen on your website or a representative sample set of pages. Strategically identifying the right pages to analyze is just as important as selecting the right testing platforms for efficient use of resources. This is why it is important to select a strategic sample of core critical unique pages to be tested such as high traffic pages, feedback forms, policy pages, the home page, contact page, landing page, pop-up modals, and search page.

Side note: You can determine all you need to by only testing 30 pages, rather than 1,000 pages. This is because many of your pages have the same code, same issues and will require the same guides.

On completion of automated and manual expert review, your a11y audit report should usually consist of:

• Executive Summary: This is a big picture of the report that will most likely specify your percentage compliance rate against the WCAG 2.0 A/AA. As a high level summary, you get how many passes and fails, user impact, and top issues. This dashboard could also be a non-technical management summary.
• Accessibility Issues Identified: This shows your success and failure. It also points out errors, browser, and WCAG issues.
• Impact: Describes your accessibility issues from the perspective of the users with disabilities. The impact board also helps categorize the barriers according to the impact. Having the issues broken down into verticles of critical, major, moderate, and minor helps to prioritize remediation.
• How to fix: The audit report should specify the WCAG 2.0 A/AA requirement failed, the impact of the failure, description of the failure, URL of the impact, techniques to fix the issues including code examples, a reference link to the W3C recommendation, and possibly a link to further learning and a background to help understand fixing the issues. This also involves a collaborative approach whereby your IT team can learn as much.

In other words, your accessibility audit report should declare the requirements failed, identify where the issues can be found, and a corrective action plan that provides instructions to remove the barriers,  charts a course to compliance, and provide access to learning resources.

On completion of the accessibility evaluation of your website, and subsequent removal of barriers and retesting to make it accessible to all web users, you will still have to maintain compliance with digital laws. This is because your website can easily fall out of compliance with any change or update to the site.  More so, a single barrier could be the reason for litigation.

To that effect, it is recommended your organization has an a11y strategy which includes accessibility statements on the site, instilling accessibility considerations in your design and development cycle, training of your IT team (developers, designers, and content creators), and maintaining accessibility by fixing any arising issue. This has been covered in a standalone article – Accessibility Compliance: How to Get Started.

Side note: After achieving compliance, monthly automated testing is highly recommended as it takes fewer resources and would give a general idea of what’s broken.

In the real sense of it, your digital accessibility projects should begin and end with an audit.