Why Should I Do an Accessibility Audit?
Audits are usually part of organizations’ accessibility journeys, but are they really necessary? In most cases, yes, but it’s critical to understand what you would audit first — and most importantly — why you should audit.
In this blog, I start with these burning questions and then talk a bit about audit objectives, creating the right scope, triaging what is found and prioritizing remediation after an audit, including best practices for ongoing accessibility compliance.
Starting the audit conversation
Many clients ask if they have to audit 100% of their app or website. To arrive at a sensible starting point, we typically examine the organizational goals and work towards that outcome. With this information in mind, we can hone in more on what specifically to audit. While it may be ideal to audit the full app or website, there are always areas that can be prioritized with the eventual goal of reviewing the whole app or site. It’s really important that organizations don’t get hung up on how big the audit might be, yet it’s a common thing that I’ve seen over time.
BLOG
Your Essential Web Accessibility Checklist
Whether you’re starting out or scaling a mature program, the web accessibility offers a roadmap for inclusive digital product development.
Are you auditing for legal reasons, to guide product/experience improvements or both? Sorting out your primary driver is key.
For example, I recently had a conversation with a prospective client whose main goal was to be compliant with the European Accessibility Act (EAA). Since the focus was legal, the scope became clearer: we needed to meet the EN 301 549 standard. To make the audit manageable and impactful, we created a strategic plan. We proposed starting with their English code base, as we believe fixing issues at the source will resolve the majority of accessibility problems across their other European language sites. At the same time, we’d focus the audit on the specific devices that have the largest user base, because that’s where the most business risk lies.
On the other hand, the strategy changes for a more mature product. We have been working for years with a large global video meeting platform company whose primary goal is ongoing product improvement, not just legal compliance. Performing a full audit against their entire, massive product set would take months and raise hundreds of issues that could overwhelm their developers. In this case, we take a more targeted approach. We break up the audits into smaller, manageable bits, focusing on specific sets of features or key user journeys to ensure continuous improvement without halting development.
Prioritization after audits
Organizations can be overwhelmed after an audit, as the audit team may raise hundreds of issues. What should be tackled first? First, let me show you how we approach the audit and how that plays into prioritization.
Example of testing processes and methods
Here’s one way we test sections of websites and apps.
Auditors are assigned to test a url or screen and begin this process:
Automated testing
- They run an automation pass, typically using AXE, WAVE or Accessibility Insights.
- The auditor evaluates the reported issues and parses out the false positives, since automated tools typically find 20 – 40% of issues and lack contextual understanding, at times flagging issues that are not barriers for users. (For more on this, read our blog Why Automated Accessibility Testing Tools Miss So Much.)
Manual testing
- Auditors navigate a URL or screen from top to bottom with a keyboard, then do the same with a screen reader.
- They test all the checkpoints not covered by keyboards/screen readers and check them off our WCAG/EN checklist to ensure all checks that apply are fully tested. Color contrast checker and developer tools are used to evaluate the source code.
- When reporting bugs, auditors capture screenshots highlighting the issue, record video to show the screen, or capture audio of the screen reader and narration by the auditor
Expert review
- Once the auditor is done with testing and reports the bugs, an expert follows up by looking at the url or screen identifying any missed issues. If additional issues exist, then they are assigned back to the auditor for follow up.
- The expert reviews the bugs for quality, proper suggested fixes, clear reproduction, video length and clarity, etc. Then the expert will either fix any issues identified in the bug or send it back to the auditor to be fixed.
Our experts try to identify patterns. For example, if we see multiple color contrast issues, or find incorrect area labels, we’ll then look to see if there’s a template being used that is the culprit.
eBook
5 Tactical Approaches To Inclusive Design In Your Organization
Learn how design and/or UX teams in organizations must own elements of an overall accessibility and inclusive design program.
Impact and efficiency in remediation
Remediating issues that have the biggest customer impact is the guiding principle post-audit. For example, if we find a screen reader cannot read a button in an FAQ list buried in the product information section of a website, but then also find that the screen reader can’t read a login button on the log in page, then there’s a clear winner in the battle for attention: The log-in button prevents a user from accessing the site, app, etc.
Actionable audit insights
In the last few years, I recall an industry consultant saying that it was a waste of time to do an audit because we already know 80%, or some similar percentage, of the areas that won’t pass. Over time, I came to understand why this guy and others deprioritize audits: it’s because so many organizations were just getting pass or fail reports that list issues but have no actionable insights. What good is that? That typically leaves developers scratching their heads.
If your third party auditor is not leaving you with insights to work on or a plan of attack to address them, then look for another partner.
Post-Audit support and VPAT
After Applause completes an audit with a client, we give them a report. It can be input directly into their Jira or any bug tracking system. It’s typically a CSV file and it contains all the information they need to identify, recreate and remediate issues. Next, we conduct a readout which also consists of a summary – so again, we’re iterative with the intention of not rushing through any of this. We highlight the most important issues we found and then thoroughly explain the details to developers and engineers and elaborate on what this means to their organization in it’s current state. We really want them to absorb this and ask us questions. This helps them digest a lot of the details.
Next, we set up one of the important post-audit actions, something we call “office hours.” These are sessions that enable team members to bring questions they have about the audit results, now that they’ve begun to work through the report. Even though they’ve become more familiar with the issues, they often still have quite a lot of questions; we’re there to suggest bug fixes and remediation strategies. We can get really specific and deep into details that help move them forward.
Once the organization has worked through the entire bug fix process, then we help them start working on their Voluntary Product Accessibility template (VPAT). A VPAT is a standardized document that highlights how your product or service meets accessibility guidelines. It is a great way to demonstrate how conformant you are with accessibility standards, and is commonly used in both public and private sectors. It’s recommended that you try to fix all that you can before authoring the VPAT.
With the European Accessibility Act (EAA) taking full effect on June 28, 2025, the requirements for digital accessibility have become more stringent. Achieving compliance with EN 301 549 and WCAG 2.2 AA is the essential foundation, but the EAA demands that products and services remain compliant throughout their lifecycle. This means any new features, content, or updates pushed after the deadline must also be accessible. A one-time audit and fix is no longer enough to manage this ongoing legal risk.
BLOG
The Basics of Voluntary Product Accessibility Templates
An FAQ-style blog that covers all of your basic questions about Voluntary Product Accessibility Templates.
The accessibility cycle
The auditing process can seem complex, especially when you consider that you’re never really “done” with accessibility. There is an ongoing and cyclical nature to keeping your products and digital real estate accessible to the broadest group of people possible.
Once through the audit, remediation process and VPAT, we typically recommend that our clients incorporate in-sprint testing during the development process. This is a proactive stance to address accessibility. The key is that as you start to develop new code, you test it right from the start, not 6 or 12 months later when you’re already out of compliance. If you get to that point, then you end up going through all that pain you’ve experienced prior, maybe even giving up sprint cycles to fix accessibility bugs.
In-sprint testing is really key to not repeating the shortcoming of the past. And, here again, an audit may be worth considering, but harkening back to an early point in this blog, it all depends what the purpose is. Is your legal group concerned, or would an audit address a key product or products, or both?
Ongoing accessibility training
The last piece of the audit ecosystem is training. Applause typically works with our clients to set up specific training based on insights from the audit. We’ll often see trends from the initial baseline audit to the benchmark audit where, for example, developers are making the same mistakes. There may be a specific checkpoint that’s a challenge for them. To address this, we can set up a customized training and precisely focus on the issue at hand and build enablement programs to support them. Strong enablement and office hours, coupled with a growing culture of accessibility throughout the organization, create momentum that organizations can use to build a perpetual high-functioning accessibility program.
Find out more about Applause’s accessibility testing and reach out with any questions.
15 min