Can You Actually Automate Accessibility Testing?

Can you automate accessibility testing?

Partly. Automated tools reliably find a meaningful share of accessibility problems and cannot see the rest at all. Deque, the company behind the axe testing engine, published a study finding that automated testing identified 57 percent of digital accessibility issues. That is a lot, and it is not most of the way there.

The number gets misused in both directions. Some teams hear 57 percent and decide automation is pointless. Others hear it and quietly treat a clean scan as a passing grade. Both readings cause problems.

What follows is how we think about the split. What to automate, what a machine genuinely cannot judge, and where to spend the manual hours you do have.

How much do automated tools actually catch?

Deque's figure came from real audit data rather than a lab. Its study, published on 10 March 2021, analysed anonymised data from over 2,000 audits, more than 13,000 pages from first time assessments, and nearly 300,000 individual issues. From that set, automated testing found 57 percent of the issues.

The reason the share is that high is volume rather than cleverness. A handful of problems appear over and over, and those happen to be the ones machines are good at spotting. Coverage measured by issue count looks much better than coverage measured by the number of WCAG success criteria a tool can evaluate.

That distinction matters when someone tells you automation covers only a third of the criteria. Both statements are true. They are counting different things, and for deciding where to spend your first hour, counting issues is the more useful measure.

What do automated tools catch well?

The common, mechanical failures, and those turn out to be nearly all the failures. WebAIM's Million report, published in February 2026 after testing one million home pages, found that 95.9 percent had detected WCAG 2 failures, at an average of 56.1 errors per page. That average rose 10.1 percent from the previous year.

More useful is the concentration. WebAIM found that 96 percent of all detected errors fall into six categories. Low contrast text appeared on 83.9 percent of home pages. Missing alternative text for images appeared on 53.1 percent. Missing form input labels appeared on 51 percent, empty links on 46.3 percent, empty buttons on 30.6 percent, and a missing document language on 13.5 percent.

Every one of those six is machine detectable. That is the whole argument for automation in one paragraph. You are not buying nuance, you are buying a cheap way to never ship the six mistakes that make up almost all of the problem. Our WCAG guide covers what each of those failures means for a real user.

What can a machine never check?

Meaning and order. A tool can confirm an image has alternative text. It cannot tell you the text says photograph when it should say the pricing chart showing the Growth plan at 400 dollars a month. Both pass. Only one helps.

The same gap applies to headings that are structurally valid but describe nothing, link text that says read more twelve times, focus order that jumps around the page, and error messages that appear visually but are never announced. Each of these is invisible to a scanner and obvious to a person in about ten seconds.

There is also the whole category of does this actually work. Can you complete the checkout with a keyboard alone? Does the modal trap focus and give it back? Does the video player let you pause before the autoplay makes the page unusable? No scanner answers those. A person with a keyboard answers all of them quickly.

Which tool should you start with?

Start with axe DevTools as a browser extension, because the barrier is nearly zero and the output names the element and the rule. Lighthouse in Chrome DevTools is a reasonable second, and it uses axe rules underneath, so the findings overlap heavily.

For checking a whole site rather than a page, Pa11y is the straightforward option and runs happily from a command line. WAVE is the friendliest for non developers, because it shows problems laid over the page rather than as a list of selectors.

Whichever you pick, run it on the templates rather than every URL. A CMS driven site has maybe twelve real templates and ten thousand pages. Fixing the template fixes the ten thousand. Our notes on semantic HTML cover why most of these failures are markup problems at the source.

How do you put this in a build pipeline?

Run the checks on pull requests, fail on new violations only, and keep a recorded baseline of the existing ones. That last part is what makes this survivable. If you fail the build on the current state of a real site, the team turns the check off within a week.

Practically, that means adding axe to your existing browser test runner, whether that is Playwright or Cypress, and asserting against a stored list of known issues. New failure blocks the merge. Existing failure gets logged and scheduled. The baseline shrinks over time because nobody is allowed to grow it.

Keep the run fast. Five key templates checked in thirty seconds gets used. A full crawl that takes twenty minutes gets skipped, and a skipped check is worth nothing regardless of how thorough it was going to be.

What do you do about failures you cannot fix today?

Write them down with an owner and a date, and be honest about the order. Not every violation is equally harmful. A missing form label blocks someone from completing a task. A slightly low contrast on a decorative caption is worth fixing and is not the same emergency.

We sort by whether the issue blocks a task, how many pages it appears on, and how expensive the fix is. Blocking issues on high traffic templates get fixed this sprint. Everything else goes on a list that gets reviewed, not a list that gets forgotten.

Avoid the overlay widget shortcut. Those products promise to fix accessibility with a script tag, and the accessibility community has been consistently critical of them for years. A scanner may report fewer errors afterwards, which is the problem, because the underlying page did not change.

How do you test with a screen reader without being an expert?

Badly at first, which is still far better than not at all. Turn on VoiceOver on a Mac or NVDA on Windows, close your eyes, and try to complete one task on your own site. Sign up, or find the pricing, or submit the contact form.

You will not use it the way a daily user does, and you will still find three real problems in twenty minutes. The unlabelled button, the link that says click here, the form error nobody announces. These are exactly the failures automation cannot reach.

Do this once a quarter on your most important flow. It is the highest value manual accessibility work available to a team with no specialist, and it costs less than the meeting where you discuss whether to do it. Our guide to accessibility in Webflow covers the platform specific version of the same checks.

Does passing an automated scan satisfy the law?

No, and nobody should read this article as legal advice. Accessibility requirements in most jurisdictions reference WCAG conformance, and conformance covers criteria that automated tools cannot evaluate. A clean axe report is evidence of effort, not proof of compliance.

What a clean scan does give you is a defensible position and a much smaller manual audit. If the six common failures are gone before a specialist arrives, their time goes into the judgement calls rather than into telling you about missing alt text.

Given that WebAIM found detected failures on 95.9 percent of home pages tested, being in the small group that scans clean already puts you well ahead of the average site. Our piece on the European Accessibility Act covers what changed for companies selling into the EU.

What would we do first?

Three things in an afternoon. Run axe on your five most important templates. Fix every contrast, label, alt text, empty link, and empty button it finds, since those are the categories that make up the bulk of real world errors. Then add the check to your pipeline with a baseline so it cannot get worse.

After that, book one keyboard and screen reader pass on your main conversion flow each quarter. That combination gets a normal marketing site most of the way to good, which is a far better position than most sites are in.

If you want help setting the pipeline up, or a review of where your templates actually stand, we are happy to take a look. You can find us at phoenix.studio.