Increased awareness of accessibility and the compliance mandates of multiple governments has led to a significant increase in the number of vendors specializing in accessibility. It’s also led to aggressively optimistic claims about features that can automatically resolve all your accessibility issues.
One common misconception with accessibility testing is that getting a great accessibility score from a tool means you’re finished. This is sometimes known as “one-tool compliance.” Automated testing tools often miss key accessibility gaps that are only discoverable when users test for the lived experience of using assistive technologies with your website.
To achieve a consistent, accessible experience, you need a system in place, not a silver bullet that magically eliminates any accessibility issues. These systems are built around tools that both easily integrate with your existing workflows and accurately provide you with the actionable feedback required to deliver on accessibility.
The core categories of accessibility tools
There are several categories of accessibility tools that are useful at different stages of your content publishing lifecycle. They also follow different implementation strategies.
Preventive tools tend to be part of the website design and development paradigm of shifting left and catching issues before they make it to your production website. Reactive tools monitor accessibility after your website is in production.
These accessibility tools generally fall into one of the following categories:
Design-phase accessibility tools
Design-phase tools validate things like color contrast before any website coding is done. This could be a Figma plugin if that’s where your site designs start, or a color contrast plugin for WordPress that runs on the non-production version of your site.
Automated accessibility scanners
Automated scanning tools assess your live site and offer an effective first pass at accessibility, catching things like color contrast, missing alt text on images, font size, font readability, and link highlighting. Automated scans generally catch about 30-40% of accessibility issues.
Manual testing with assistive technologies
Manual testing tools assess the actual lived experience of users who engage your site with assistive technologies. Examples include:
- Using screen readers to test for read-aloud compatibility.
- Keyboard navigation for moving around on the page and assessing the focus order of forms and buttons.
- Zoom levels to understand how well aspects of your site perform for users with low vision.
CI/CD and developer accessibility testing (shift left)
CI/CD and developer-focused testing tools are the shift-left approach to automated testing. By integrating automated testing before pushing website code to production, you prevent accessibility issues before they occur. Some common developer accessibility tools include:
Monitoring, reporting, and accessibility platforms
Monitoring and reporting platforms help ensure your site remains accessible by providing ongoing insights. Some popular accessibility monitoring solutions here include:
Governance: VPATs, ACRs, audit trails, legal documentation
A governance layer should work in combination with all these tools to track things like Voluntary Product Accessibility Templates (VPATs), Accessibility Conformance Reports, and any legal settlements or agreements associated with accessibility.
How enterprises actually compare accessibility tools
When it comes to choosing accessibility tools for your organization, there are several factors to consider. While the core reason for improving accessibility is to enhance user experience, the reality is that accessibility also involves risk mitigation. The following factors are useful when considering both:
Coverage vs. accuracy (false positives)
Tools promise to catch everything. What they do catch needs to be accurate. There’s a delicate balance to manage between trying to get too much coverage from a single tool vs. making sure what is covered is accurate. One key here is understanding the false positive rate. How often is the tool telling you something is wrong that isn’t?
Ease of use by role (design, dev, QA, content)
When it comes to accessibility testing, what’s easy to use for your software developers won’t be the same as what’s easy for your content team, QA team, designers, or anyone else involved in maintaining consistent accessibility standards. It’s important to understand both what a tool does and who will use it.
Workflow integration (CMS, CI/CD, ticketing)
Identifying which tools are compatible with your CMS, your developers’ CI/CD workflows, and your bug tracking systems helps ensure tools fit into how you work.
Reporting, audit trails, and compliance documentation
Part of mitigating risk is having the documentation to know what changed, when it changed, and who changed it. Supporting this need is a key factor when choosing a tool.
VPATs and vendor accessibility
When accessing a vendor, it’s also important to understand how accessible their tools are. A VPAT basically lets you know whether the tool is WCAG-compliant or not.
Cost, scale, and operational overhead
Understanding both upfront and ongoing tooling costs can be critical to avoiding budget surprises. Operational overhead also contributes to costs when tools add complexity to existing workflows.
Actionability: Does it tell you how to fix issues?
Is the tool telling you how to fix the problems it identifies? This is key to keeping operational overhead low.
Why enterprises use multiple accessibility tools
While it would be great to find the one tool to achieve all of your accessibility outcomes, the reality is that most enterprises end up using several tools. Part of this is due to the limits of automation. Automating at the design and code level can catch some issues, but manual testing will still be required.
When it comes to choosing tools, you will likely end up with some that overlap in functionality. While it’s generally a waste of your budget to pay for two or more things that perform the same function, it can be useful to include intentional redundancy to validate accessibility at different points in your content publishing lifecycle.
One key thing to avoid is any tool that promises to fix your accessibility issues with a “one-line-of-code” solution. These solutions might mask accessibility, but they do not fix the problem at its core. There is an increased risk to your organization in trying to use these shortcuts.
Operationalizing accessibility tooling in CMS workflows
Having an ongoing testing plan in place is important, but key moments in the life of your website, like migrations, redesigns, and major releases, are crucial moments to use accessibility tooling. Without testing, your design team may introduce an incredibly innovative new website look that is entirely inaccessible to anyone who needs assistive technology.
This is where assigning ownership across teams is crucial. Have clear owners at each stage, from design to development, all the way to the team publishing new content on a regular basis. Have clear roles for each of those owners, specifying what they are responsible for.
One way to prevent regressions and operationalize accessibility is to leverage atomic elements of your website. When you maintain accessibility at the source, like at the block or template level, you can cascade accessibility across your site without needing to make page-level changes. It’s still important to validate that page-level accessibility is maintained, but the overhead to check will be much lower.
The same analytics you use to measure your website’s success can also be used to manage your accessibility efforts. The most visited content will have the greatest impact on your site’s accessibility. When you’re looking for a place to start, the top content list is a great place to begin.
What CMS choice changes about accessibility tooling
Choosing the right CMS can make accessibility easier (or more difficult). Platform architecture affects your ability to integrate tools. For example, the WordPress plugin architecture makes it easy to integrate a number of accessibility tools.
Your CMS can also address issues around governance, user roles, and workflow enforcement. When your CMS lets you to dictate who can change which aspects of your website, you maintain better control over who changes elements that affect accessibility. You also get an audit trail to track those changes. Workflow enforcement can further improve accessibility by requiring specific steps prior to submitting content changes.
The previous section mentioned changes at the atomic level. This is another area where the CMS does the heavy lifting. WordPress lets you to create reusable blocks and templates that maintain the same accessibility when used across different parts of your website.
Choosing tools is easy; building a system is hard
It can be tempting to view a high-end accessibility scanner and its scoring system as an easy accessibility fix. In reality, that tool is only as effective as its role in your workflow. If the scanner finds 572 errors but those errors never reach your bug-tracking backlog or the content team’s CMS dashboard, the tool is a failure.
Moving from chasing errors on your pages to proactive digital inclusion is the real sign of accessibility maturity. Most organizations start by finding and fixing errors on their live site. As they mature, they shift left to fixing issues before they go live by updating designs, adding testing to the CI/CD pipeline, and empowering the content team to make fixes at the block and template level.
Focusing on process and platform in your tooling choice and accessibility strategy leads to a more successful accessibility program. A CMS that enforces structured data and accessible components helps reduce the number of errors an accessibility scanner needs to catch. Adding process at the development layer, like requiring an automated check prior to code merge, puts accessibility on equal footing with other quality signals like security and performance.
As your accessibility journey matures, you can be more strategic in how you evaluate new vendors and tools. There is no “perfect” accessibility tool. Look beyond the features a vendor promises and ask:
- Does this tool integrate with the way we work?
- Is the feedback actionable for the intended role (design vs. dev vs. content)?
- Can it scale across our organization without wearing out the team with constant alerting?
Frequently asked questions
Can we achieve 100% compliance using only automated tools?
Fully automating both the identification and resolution of accessibility issues remains aspirational. Automated detection typically catches 30-40% of issues that fail Web Content Accessibility Guidelines.
Solutions that promise automated fixes often mask the problem rather than resolving it. Complex issues like logical tab order when using a keyboard, screen reader performance, and context-relevant alt-text require manual human testing.
How can we integrate accessibility testing without slowing down our CI/CD pipeline?
This is the core of a “shift left” approach. Enterprises want to know how to use linters and automated gating with tools like Axe-Core or Playwright integration to catch errors during the pull request phase of development. The goal here is to catch issues before a reactive approach is required in production.
How do we evaluate the accessibility of our vendors?
One more recent aspect of accessibility is ensuring your third-party vendors, like SaaS tools, HR portals, and CMS, are accessible. The vendor needs to provide a voluntary product accessibility template (VPAT), which helps your organization avoid inherited liability.
How do we manage accessibility scanner “error fatigue” on large websites?
When the scanning tool reports thousands of errors, the best approach is to start by looking at how they are categorized. Which issues address meeting WCAG Level AA vs. Level AAA? You can prioritize based on your organization’s accessibility goals.
This is also where leveraging atomic corrections at the block or template level in your CMS can quickly drive down the total number of errors by fixing the issue at a common source component rather than trying to solve it at the page level.
Related content
Website Accessibility Standards for Businesses
Jake Ludington
Jake is a technology writer and product manager. He started building websites with WordPress in 2005. His writing has appeared in Popular Science, Make magazine, The New Stack, and many other technology publications.