The key to auditing the accessibility of a website is rigorously inspecting and testing the code and the content against a baseline of technical standards.
With an audit, we are essentially grading a website against the standards and writing down every single instance where the website didn’t meet a requirement.
In this guide, we’ll cover the essentials to finding the accessibility issues on a website.
Demand for digital accessibility audits has skyrocketed in recent years due to ADA website lawsuits, but it’s important to remember that the term, ADA Website Compliance audit, is a colloquial term as we are auditing based on technical accessibility standards, specifically the Web Content Accessibility Guidelines.
To explain auditing, we’ll break it down into 15 parts, starting with the definition.
Table of Contents
What is a Website Accessibility Audit?
An accessibility audit is a formal, manual evaluation of a website or other digital asset conducted by one or more technical accessibility experts. The audit is based on a specific set of standards and results in a final report, typically in Excel spreadsheet or occasionally PDF format.
What is the objective of an Audit?
The objective is to find all accessibility issues within the named scope. The secondary objective is to make the audit report easy for the client to understand so they know exactly what the accessibility issues are and how to fix them.
Define Technical Standards
Before we evaluate a website, we must define the standards to be used during evaluation. In most cases, we use one of the three versions of the Web Content Accessibility Guidelines (WCAG):
- WCAG 2.0 AA
- WCAG 2.1 AA
- WCAG 2.2 AA
The higher the WCAG version, the more success criteria we will need to account for.
Define the Environments
Next we must define the environments under which the audit will be conducted. Environments include:
- Browsers
- Operating Systems
- Devices
- Assistive Technologies
The more environments we use, the more robust our audit is because we’re ensuring there are no accessibility issues across many different types of environment combinations.
Adding more environments to the audit process is beneficial in theory, but, in practice, for every additional environment added, the time and cost of the audit increases. Because of the time and money involved, it’s best to limit environments unless the website receives a high amount of traffic or we know through analytics that certain environment combinations are highly used.
An audit using the environment combination of Windows Desktop, Google Chrome, and NVDA screen reader is quite common. Also, including Safari browser, VoiceOver screen reader, and an iPhone is common due to Apple’s popularity.
For reference, here are other widely used environments:
Browsers: Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari.
Operating Systems: Windows, macOS, iOS, and Android.
Devices: Desktop / Laptop, Smartphone, Tablet
Assistive Technologies: Screen readers (JAWS, NVDA, VoiceOver), Screen magnifiers, Speech recognition Software (Dragon Naturally Speaking)
Define Scope
The scope of a website accessibility audit specifies all URLs / pages, screens, domains, and subdomains that the audit will span. In most cases, the audit should only include one digital asset (e.g., a website, mobile app, or software). If audits for multiple assets are needed, they should be segmented into separate audits.
The scope for most website accessibility audits will be the primary pages / page layouts for the website.
For example, the following pages of an ecommerce website would be audited:
- homepage
- product search page
- product page
- checkout
- registration page
- account page
When defining the scope, we want to make sure that all of the pages / layouts that receive the most views and/or have the most activity are audited.
Most websites usually have 7-15 pages in scope.
When the audit report is received, the digital team can then apply changes to other similar pages, layouts, or content. Many changes will be applied sitewide because the layout template for a page will be updated.
Evaluation
With all of the parameters defined, it’s time for the auditor(s) to begin evaluating the website.
There are many different approaches and starting points when it comes to evaluation including:
- Working from top to bottom and left to right of each page
- Working from a WCAG checklist
- Working from scan results first (scan results must always be manually reviewed)
- Looking for certain accessibility issues first
- Starting with the header and footer of a website
- Starting with keyboard navigability
Whatever method is chosen, the most important result is that all of the accessibility issues are found and reported on.
How to Evaluate Accessibility
The ability to find accessibility issues is mostly intuitive if you’re familiar with the Web Content Accessibility Guidelines (WCAG) because those are the technical standards that we’re grading a website against.
For example, for success criteria 2.1.1 Keyboard and 2.1.2 No Keyboard Trap, we will keyboard test to ensure that we can fully interact with all functionality on a website using only a keyboard and that at no point in time are we trapped on a website if we are using a keyboard.
In other words, WCAG success criteria basically tell us what we need to evaluate by what they require for conformance.
As another example, success criterion 1.2.2 requires closed captions so we need to make sure our videos have closed captions.
Thus, the material aspect of learning how to audit comes down to understanding the different WCAG success criteria. As a primer to start learning WCAG, we highly recommend our WCAG 2.1 AA checklist.
But simply knowing what accessibility requirements to look for doesn’t mean you will intuitively be able to identify and test for them. This is because checking for some accessibility issues requires more advanced knowledge.
For example, an audit requires screen reader testing as a part of the process. If you do not know how to use a screen reader, then you can’t fully evaluate some success criteria.
As another example, an audit requires inspection of code. If you’re not experienced in evaluating code, you will not be able to fully evaluate for some of the more technical accessibility considerations.
That said, even if you don’t have a technical background, you can still identify several important accessibility issues. And, remember, audits can be conducted by more than one accessibility expert.
Overall, the comprehensive evaluation of the accessibility of a website involves a combination of the following methodologies:
- keyboard testing
- screen reader testing
- visual inspection
- code inspection
- automated scans*
*Automated scans are not absolutely necessary, but they do help in auditors checking and making sure they didn’t miss any issues that can be flagged by automation.
Report
After all accessibility issues have been identified, they are compiled into a final report that will be delivered to the client.
The final report typically includes a summary along with important details including standards used, environments used, date, and other information pertinent to the report.
The material aspect of the report will always contain an organized list of the accessibility issues found and then may include the following details associated with each issue:
- Associated WCAG success criterion
- Location of issue
- Steps to reproduce the issue
- Screenshot, video clip, or code of issue
- How to fix the issue
- Sample code
These additional details are all designed to make it easy as possible for the client or remediation team to fix the issues in the final audit report.
Audit vs. Automated Scan
The term audit is sometimes used to describe an automated scan whereby the scan will be referred to as an “audit” or “automated audit.” This an incorrect usage of the terms as audit always indicates the manual evaluation of a website or other asset.
Although scans are sometimes used during the course of an audit, audits are never based on automation; all scan results must be manually reviewed.
Audit vs. User Testing
The terms audit and user testing are often conflated, but they are two different methods of assessing the accessibility of a digital asset.
Even though an audit involves screen reader testing and keyboard testing, it is not user testing. Rather, an audit is the formal, technical evaluation of a website against WCAG or other standards by one or more technical accessibility experts.
In contrast, user testing is always conducted by an accessibility professional with one or more disabilities, typically using assistive technology. In the context of websites, user testing is typically conducted by a professional who is blind or visually impaired and using a screen reader. However, user testing can be conducted by professionals with different disabilities and assistive technologies.
During user testing, the professional will relay their practical experience in using the website for a set duration of time (e.g., 50 minutes). Compare this to an audit where the audit is not complete until every page within the scope is evaluated.
In a nutshell, the key differences between an audit and user testing are:
- Conducted by experts with or without disabilities vs. conducted only by professionals with disabilities
- Technical vs. practical evaluation
- Based on standards vs. based on experience
- Comprehensive vs. limited by parameters
Audit Resources
If you need help auditing and/or remediating a website, Accessible.org offers both accessibility audit and remediation services.
If you would like to learn more on how to conduct a basic website accessibility audit, sign up for our course, Audits 101, which goes in-depth on how to audit for accessibility and create a report.
