What is a web accessibility audit?
It’s much like any other audit you might undertake. In this case, it’s an examination of your website (and possibly other digital assets) to determine where there might be gaps or barriers relating to accessibility for someone who might be using the site.
Ideally, an audit is done by experienced professionals who are knowledgeable in web accessibility. (This is something you—or your team—can do yourselves, as we’ll discuss below. But if you’d like the help of a team of web accessibility audit professionals, we’re happy to help! You can always reach us through our Accessibility Audit Services page.)
Wait—what’s accessibility?
Great question! Accessibility is the colloquial term used to describe how easy it is for a product (in this case, a website) to be used by a person with disabilities. The more accessible, the better—both for people using the website, and for those with websites, in terms of meeting the needs of visitors and in achieving legal compliance.
There are several standards that you can use to measure how accessible a product is, and, depending on the industry, laws and regulations may require compliance. Most require some level of compliance with the Web Content Accessibility Guidelines (WCAG) and we generally recommend that websites meet the criteria described by Level AA of the latest approved version of WCAG. That way, not only is the website more usable by people with disabilities, it also helps future-proof the website.
Why is a web audit important?
Not to put too fine a point on it, but a web accessibility audit is important because accessibility is important.
Accessibility web audits show you where gaps and barriers related to accessibility are so they can be fixed. Not only does fixing gaps and barriers help users to access and understand the content you’re providing, it helps broaden the reach of the site overall.
Figure 1: Accessibility helps broaden the reach of websites (and products!).
What happens when a web audit is done?
When a web audit is done (either by you, someone on your team, or a professional auditor), the first step is to scope out what is going to be audited. It might be a web page, or a web application, or an entire website. Scope might focus on publicly facing content, or possibly an internal intranet site.
After you’ve identified the scope, the auditor will often follow a process to methodically test the content against specified criteria.
Note that an audit is mostly a manual process. There are automated inspection tools that can help, like WebAIM’s Web Accessibility Evaluation Tool (WAVE). However, such automated tools often identify only 30%-40% of accessibility issues. It’s essential to keep a human in the loop, so that the audit is comprehensive.
An auditor might work their way through each page, testing with accessibility tools such as a screen reader to make sure that the content is read is the same way that a sighted person might read it. This might be followed by using only the keyboard (not the mouse or other pointing device) to make sure that a user with a mobility impairment can navigate and access all the content.
One element of an audit that’s commonly overlooked (especially by automated tools) is the meaning of the content itself. Let’s say you have, on the site, a widget that someone has built themselves. The widget is effective at what it does, but there aren’t any directions on how to use it.
That’s a barrier—the user can’t complete the task. It’s not something that you would see when reviewing a web page template or looking at a cascading style sheet (CSS). But it’s still an accessibility issue that needs to be addressed.
Once all the testing is complete, the auditor will usually use the results of the testing to create an audit report. An audit report lists each barrier, describing what the barrier is and who it impacts. The report will also list how the barrier might be remediated, or fixed. Auditors will often include screenshots to help illustrate the issue. If the audit is done by an external auditor, they’ll provide an overall list of resources if you’d like to do testing on your own.
Figure 2: Sample from an audit report showing description, priority, success criteria, remediation steps and a screenshot of the issue.
The auditor may also provide graphs, tables, and additional data so that you can see which pages tend to have the most issues, and possibly suggest the relative priority of the issues they found—so, in a time of limited resources, you’ll be able to make a decision as to what needs to be addressed first.
Figure 3: Sample issue breakdown, priority, and summary.
How much does it cost for a professional to do a web audit?
It depends. A three-page website isn’t going to take very long and would likely be fairly inexpensive. A large, complex web application might take a couple of weeks to audit and would cost more. Cost essentially depends on the size and complexity of the product.
Another factor is the number of issues the site has. A four-page website where the developers have paid some attention to accessibility (maybe they’ve made sure that color contrast meets the standards, or they’ve done a quick keyboard test to make sure that you don’t have to use a mouse, or they’ve run an automated checker and fixed the issues that the checker found), might take a day and a half at most. But the same site where the developers didn’t even consider accessibility might mean it would take an auditor three, four days to complete the audit and write up the report.
What’s the difference between being accessible and being compliant?
That’s a great question. Being compliant means that you’re adhering to the standards regarding making content available to those with disabilities. That might mean Section 508 of the Rehabilitation Act if it’s for a federal agency in the United States, or Title II of the Americans with Disabilities Act if it’s for a state or local government. In Europe, websites have to comply with EN 301-549.
Being accessible, on the other hand, means ensuring that the website is usable—when a website is accessible, it’s more capable of being used by everyone, including those with a disability.
Sometimes there’s the thought that if a website is compliant—it meets the letter of the law—it’s accessible. That’s not always the case. Different people might use different technologies (or might use similar technologies in different ways) to access the information and perform the tasks on a website. The goal is to go as far as possible in reducing all barriers, not just checking off boxes on a list of standards.
Figure 4: Using a Braille display to access information.
It can be helpful to think of accessibility as a journey, and meeting the standards is the starting line, not the finish line. Accessibility isn’t something that’s ever really finished. Websites are constantly changing, as are the technologies that people with disabilities use to access them.
What do I do if my product is not accessible?
Fix it. (That’s the short answer.)
And don’t panic. Fixing the site is doable. A website’s mostly just HTML—and there aren’t really a lot of things going on with accessibility that would require you to completely relearn HTML. It’s mostly minor additions to what designers and developers probably already know.
The first step is to get a sense of where the website is in terms of accessibility, which is why an audit is essential. If you’ve gotten an audit report and there are numerous defects that you need to address, prioritize and address the most important issues.
And then it’s good practice to incorporate addressing issues that the audit reveals into the regular quality assurance and software development cycle. Building accessibility into the process, addressing it as the team designs and develops websites, is the surest way to both maximize accessibility and minimize the need to remediate the website after it’s published.
There are a lot of resources out there to help you do that, especially with complex widgets and with the use of more technical approaches like WAI-ARIA. (If your audit is professionally done, the auditor should provide you with guidance on how to address the issues and resources and links to help you follow that guidance.)
How do web pages get remediated for accessibility?
It’s really a matter of going through the issues on the audit report, addressing them using the guidance that it provides, supported by the resources that the audit report makes available. Most things are pretty simple and can be handled at the template level or in the CSS, although some issues may require a more involved approach, such as reworking scripting that governs the site, or including a designer for their input.
Once things are fixed, it’s essential that website is checked to ensure it behaves in the way that it’s supposed to—that the issues noted in the audit no longer occur. When it’s something visual, like color contrast, it’s pretty easy to check (use a contrast checking tool, plug in the numbers, and verify that the content passes).
If it’s a screen reader issue (that is, an error encountered by someone using a tool that allows someone to navigate the website by hearing it read to them), that might be a little more complicated, as you’d need to use a screen reader to make sure that the issue no longer occurs (there are screen readers that are built into operating system and other that are free).
What happens if I do not or cannot remediate my website?
If you decide not to remediate your website, that opens up some risk. The barriers that would prevent someone from accessing the website aren’t removed. If, for example, the website is for a local restaurant and the online menu isn’t accessible, someone who’s blind and tries to see what’s on the menu won’t be able to. In that case, that restaurant might lose business—they might just not go to your restaurant.
There’s a more serious risk of a lawsuit as well. Restaurants (and other organizations) have been sued when their websites aren’t usable by people with disabilities.
Can I do the audit myself? How would I do it?
Sure! There’s no secret to performing an accessibility web audit, and there are plenty of guides and training available. Performing an audit does require specialized knowledge, and that can be learned. Something to note is that in some cases doing a third-party audit—having an external party validate the content—can help establish a level of objectivity and confidence in the results.
One other thing to note is that several organizations have developed accessibility auditing tools that function as software-as-a-service. There’s usually a cost, but working with such auditing software can help provide the tools to use to ensure that websites are accessible.
I want someone to do the audit for me—how would that work?
If you want someone to do the audit for you, one of the first things that a professional audit team will do is walk you through their process, and explain pretty much everything that we’ve been discussing here—what an audit entails, what it affects, how it helps you, and similar topics.
You’ll work with the auditing team to scope out a representative sample of work. Generally speaking, if you have a 1,000-page website, the audit wouldn’t review each, but look at a sample instead. They’ll perform the audit and provide you with reports, including guidance on how to fix everything that the audit discovered.
They may—and should—offer a verification process. That is, once you’ve addressed the issues, they’ll go through the site and audit report again and verify that everything in the report has now been addressed.
If you’re more focused on procurement (that is, you need to share with potential buyers that a product you created is accessible), that’s a different process, one that will result in a Voluntary Product Accessibility Template (VPAT), also known as an Accessibility Compliance Report. It’s basically a statement that says your product has been evaluated against a specified accessibility standard for a specific point in time. You’d then be able to share that with your clients as a statement that your product is accessible. (We’ve got a guide on VPATs, too.)
Can’t AI do this?
Maybe. To a certain degree. In theory, AI should be able to read through the content and digest it in the same way that a human would. At the same time, as mentioned earlier, most automated tools that are currently available (including tools that incorporate AI) catch only 30%-40% of the issues.
It’s likely that, given the current state of AI and AI-driven tools, they can help support someone doing an audit, but it’s unlikely AI could, on its own, replace the need for a human-driven audit.
I’ve audited and remediated my website. What now? My website is fully accessible now, right?
Maybe? If you have a very small, three-page website that never changes, and has only basic issues that are quickly fixed, it’s possible that you’re done.
But it’s more likely that’s not the case. Websites change. They update their content. They add new pages, remove old pages, add product pages or maybe blog posts. They might go through site redesigns.
Every time a website changes, there’s a possibility that something has happened that means the site no longer meets accessibility standards. Maybe someone used inadequate color contrast, or didn’t verify alternate text on an image, or added a button that screen readers can’t access.
This is one of the key reasons accessibility testing works best as part of an overall design and development cycle. Incorporating accessibility testing into a process will help make sure that barriers are kept to as much of a minimum as possible throughout the lifespan of the website.
How will ADA Title II changes affect web audits?
Great question! Please take a look at Microassist’s resources on Digital Asset Accessibility Under ADA Title II. April deadline.
Going Forward
Accessibility’s a journey. Website change, accessibility tools change, sometimes, if only rarely, accessibility standards change.
It’s essential that web audits are done, and it’s best if both the audit and addressing accessibility issues are part of the overall design and development process.
You can do this—it requires specialized knowledge, but there’s been a recent growth in guidance, resources, and training that focuses on making all kinds of digital products accessible.
If you’d like some help, either with auditing websites, or remediating documents for accessibility, or getting training on how to do this yourself, please don’t hesitate to reach out!
Recommended Resources: Document Remediation and Digital Accessibility
- To keep up to date with digital accessibility standards, private and public sector trends, litigation, events, and more, subscribe to Accessibility in the News.
- The ARIA Authoring Practices Guide (APG) is a great tool that describes how to apply accessibility semantics to common design patterns and widgets.
- For more information about the deadlines and exceptions for public entities under the April 24 revision to the Americans with Disabilities Act (ADA) Title II regulations, see Navigating WCAG 2.1 Compliance Deadlines and Exceptions for Public Entities.
- For more information about the training needed to satisfy the new ADA Title II regulations, see Training Needed to Satisfy New Web Content and Mobile App Accessibility Requirements for State and Local Government Entities.
- For general information about the April 2024 revision to the ADA Title II regulations, see Microassist’s Digital Asset Accessibility Under ADA Title II
- For a do-it-yourself guide for web auditing, see Professional Web Accessibility Auditing Made Easy Subtitle: Essential Skills for Web Developers, Content Creators, and Designers, by Digital Education Strategies, The Chang School.
- For a free foundational course, see Introduction to Web Accessibility.
Subscribe to Accessibility in the News
Stay informed! Get your weekly update on digital accessibility standards, private and public sector trends, litigation, events, and more.