Automated-only accessibility testing looks like a bargain. You point a tool at your website and wait a minute. Back comes a report. It lists problems, sorts them by severity, and hands you a tidy score. The report feels thorough and final. It is neither–it’s really just the first step.
These tools earn their place in any serious accessibility program. Fast and consistent, they scale across thousands of pages without complaint, never flagging, never skipping a step. The problems they surface are real and affect people. But a scan catches only a slice of potential issues, and the slice it misses tends to hold the problems that lock people out.
What are “automated accessibility tools”?
Automated tools shine at catching clear, mechanical problems that follow a predictable pattern. You may already be using one. Common examples include Siteimprove, Monsido, WAVE, Axe, Lighthouse (built into Google Chrome), and–AndiSites’ favorite–Equalize Digital’s Accessibility Checker for WordPress. These tools flag issues like low-contrast text, images with no text alternative, form fields missing a label, and pages with no language declared.
An automated scan gives you a fast, repeatable baseline, and it catches the kind of accessibility issues that creep back in every time someone publishes a new page. Run one before launch. Run one after every major update. Build it into your routine and you’ll stop a steady drip of avoidable issues before they reach the public.
So use these tools. Just don’t mistake them for the finish line.
How much can automated tools catch?
Experts disagree on exactly how many accessibility issues automated tools can catch. Figures commonly cited range from a quarter to a third of issues, with some tool makers claiming higher ceilings under ideal conditions. Others argue that in practice, when you account for dynamic content and anything requiring context or interaction, the real detection rate is much lower. The number varies depending on the site, the tool, and how you count. But there is no disagreement on the core point: no tool catches everything, and the gap between what a tool finds and what a thorough manual review finds can be significant.
A page can earn a perfect automated score and still have many accessibility issues, because the tool never tested for them in the first place. A clean scan doesn’t tell you that your site is accessible. It tells you that your site cleared everything a machine knows how to check.
Where automated tools fall short
Sometimes a tool catches a problem and the diagnosis is clear. Text either meets the contrast requirement or it doesn’t. A missing label is a missing label. But many issues require context and judgment that no tool can supply. Think of a metal detector at an airport. It beeps when it senses metal, but it can’t tell a belt buckle from a bomb. A person still has to look. The following are some of the places in web accessibility where the same is true.
Whether image descriptions mean anything
A tool confirms that an image has a text description (called alt text) attached to it in the code. It has no way to know whether that description conveys what the image shows. A blind visitor relying on a screen reader (software that reads content aloud) gets the words you wrote, informative or useless, and only a human reviewer can tell the difference.
Whether the page works without a mouse
Some people can’t use a mouse, instead relying on other ways to navigate, like a keyboard or voice control. They tab through your page, open your menus, fill out your forms, and submit them, all without a mouse. A tool can check whether the right technical ingredients are present, but it can’t sit down and complete the task the way a person does. It can’t detect when a user gets trapped inside a menu that won’t close, or finds a button the keyboard can’t reach.
Whether page content follows a logical order
When navigating a page sequentially, a user encounters content and controls in a set order. That order should make sense for the task at hand. For someone who can’t see the visual layout of the page, that order is their only guide. A sequence that jumps around or doesn’t follow the flow of the content can leave a user disoriented or cause them to miss information entirely. An automated tool can confirm some structural signals, but it has no way to judge whether the order matches how a person would expect to move through the page. Only a human tester, working through the page the way a user would, can catch that.
How automated and manual testing complement each other
Think of the two approaches as partners with different jobs. Automated scans give you breadth. They sweep across every page, catch the predictable issues, and stand guard against the ones that sneak back in over time. Manual review gives you depth. A trained tester uses the same tools that people with disabilities rely on to navigate the web, evaluating the judgment calls that no automated tool can make.
At AndiSites, we use Equalize Digital’s Accessibility Checker Pro as part of every accessibility project. For WordPress sites, it provides on-demand reporting and check-as-you-edit feedback that helps catch issues before they reach the public. But we pair it with hands-on manual testing, because no tool, however good, can make the judgment calls that a trained human can.
An automated scan is a great first step in making your website fully accessible, but treat it as the starting line, not the finish.
AndiSites can perform both automated and manual testing on your website–and remediate the issues that it finds. Need help getting started? Contact us. We’re here for you!