February 18, 2025 · reala11y team

Automated vs Manual Accessibility Testing: Why You Need Both

Scanners catch roughly 30–40% of WCAG issues by criteria. Here's what automation finds, what only a human can judge, and how to combine them.

If you run a WordPress site, you have probably seen a tool promise to “make your site accessible” with one click. It cannot. No automated scanner can. But that does not make scanners useless — it means you need to understand exactly what they do and do not do, and pair them with something they can never replace: a human.

Here is the honest breakdown.

What the numbers actually say

Independent analyses from Deque and Accessible.org put automated detection at roughly 30–40% of WCAG success criteria. Look at it by issue volume instead of criteria and the figure rises — Deque’s 2021 study across thousands of audits measured axe-core coverage around 57%, largely because color contrast alone accounts for a huge share of real-world errors and is highly automatable.

Both framings are true. The takeaway is the same: automation handles a meaningful slice, and a majority of WCAG still needs human judgment.

What scanners catch well

Machines excel at rules with a clear, deterministic answer. A scanner can reliably flag:

• Missing alt attributes on images (whether the value is correct is another question — more on that below).
• Color contrast ratios below the 4.5:1 threshold for normal text.
• Skipped heading levels — an <h2> jumping straight to an <h4>.
• Form inputs with no associated <label>.
• target="_blank" links missing rel="noopener".
• Duplicate id values and empty buttons or links with no accessible name.
• Viewport meta tags that block pinch-zoom with user-scalable=no.

These are code-level facts. Either the attribute is present or it is not. This is the territory reala11y scans for and, where safe, fixes at the source rather than papering over with an overlay. (See how it works for the render-time approach.)

What only a human can judge

The other 60–70% resists automation because it requires meaning, not just structure. A scanner sees the markup; it cannot see the intent.

• Is the alt text any good? A tool confirms alt="image" exists. Only a person knows that text describes a bar chart’s data rather than just saying “chart.”
• Does the link text make sense out of context? “Read more” is grammatically fine and machine-invisible as an error in isolation. A human notices five identical “read more” links going to five different places.
• Is the reading order logical? DOM order can pass checks while the visual layout tells a different story to a sighted user than a screen-reader user.
• Keyboard and focus journeys. Can you actually complete a task — open a menu, fill a form, dismiss a modal — using only the keyboard? That is a workflow, not a single attribute.
• Does the content make sense? Captions that match the audio, error messages that explain the fix, instructions that do not rely on “the red button” alone.

These are exactly the criteria — WCAG 1.3.2 Meaningful Sequence, 2.4.4 Link Purpose in Context, 2.1.1 Keyboard — where a clean automated report can hide real barriers.

Why this distinction matters now

The regulatory backdrop has sharpened. WCAG 2.2 became a W3C Recommendation on 5 October 2023 (WCAG 2.1 dates to 2018). The US DOJ finalized its ADA Title II web rule in April 2024, and the European Accessibility Act became enforceable on 28 June 2025.

And on 21 April 2025, the FTC entered a final order against accessiBe — a $1,000,000 penalty — over claims that its automated overlay made sites conformant. The lesson for site owners is direct: a tool that claims to do it all is a liability, not a shield.

How to combine them

A practical workflow for a WordPress team:

1. Run automated scans continuously to catch regressions cheaply — every new post, every theme update. This clears the high-volume, deterministic issues fast.
2. Fix what is safe to fix automatically at the code level, and queue the rest for review.
3. Schedule periodic manual review — keyboard-only passes, a screen-reader walkthrough of key flows, and human review of alt text and link purpose.
4. Document where you stand honestly in an accessibility statement, rather than asserting a conformance level you have not verified.

Automation is your smoke detector. Manual testing is the inspection. You want both. Our WCAG 2.2 guide maps which criteria fall on each side.

The honest takeaway

reala11y helps your site move toward WCAG 2.2 AA conformance by detecting common issues and remediating the safe ones at the source — not by hiding them behind a widget. But no plugin, ours included, makes a site fully conformant on its own. Use automation to do the repetitive work well, then give a human the judgment calls only a human can make. That combination is what actually reduces barriers for the people using your site.