Accessibility guide

Automated vs Manual Accessibility Testing: What Each Finds and When to Use Them

Automated tools such as AccessibilityScore.in test a page in seconds; a manual audit takes an expert hours or days. Both find real problems, but different ones. This guide compares them with published data and shows how to combine them.

Last reviewed 16 Oct 2026 by the HalfAccessible accessibility team

Short Answer

Automated accessibility testing uses software to check code against WCAG rules, finding repeatable issues like low contrast and missing labels in seconds. Manual testing uses people, keyboards and screen readers to judge meaning, behaviour and whole tasks. Automation finds many common issues, but only manual testing can confirm WCAG conformance, so effective programs use both.

Key facts

Automated share by issue volume: About 57% of issues in Deque's study of real audits
Barriers no tool found: 29% of 143 test barriers were missed by all 10 tools in a GOV.UK study (2017)
Best single tool in that study: Found 37% of the barriers, counting errors and warnings
Pages with automatically detectable failures: 95.9% of the top one million home pages (WebAIM Million, 2026)
What only people can judge: Meaningful alt text, logical focus order, understandable errors, screen reader experience
Recommended approach: Automated checks on every release, manual audits of key journeys before conformance claims

What does automated accessibility testing find?

Automated tools load a page, read the DOM, styles and accessibility tree, and apply rules that can be decided from code. They are fast, consistent and cheap to run on every page and every release. AccessibilityScore.in runs axe-core plus its own rules in a real browser and typically reports:

Colour contrast below WCAG thresholds
Images, links and buttons without accessible names
Form fields without labels
Invalid or conflicting ARIA
Missing page language and title
Pointer targets smaller than 24 by 24 CSS pixels

What does manual accessibility testing find that tools miss?

Many WCAG criteria are about whether something makes sense or works for a person. A tool can confirm that alt text exists, not that it is right; that a button has a name, not that the name describes what it does. In the GOV.UK study, barriers missed by every tool included links identified by colour alone and long passages in italics.

Manual testing covers:

Whether text alternatives, headings and link text are accurate and meaningful
Keyboard-only completion of real tasks, and focus order
How a screen reader announces content, forms, errors and live updates
Captions, transcripts and audio description
Readable, understandable content and error recovery
Behaviour across pages, such as consistent navigation and help

How much of WCAG can automated testing cover?

It depends on how you count. Measured by volume of issues on real sites, automation catches a large share because the most common problems, such as contrast and missing labels, are automatable: Deque's analysis of its audits put it at about 57%. Measured by barriers designed to cover the range of WCAG, coverage is much lower: in the GOV.UK test the best tool found 37%.

Measured by success criteria, few can be fully decided by a tool. A clean scan therefore means "no automatically detectable failures", never "accessible".

How should you combine automated and manual testing?

Use each for what it does best:

Run automated scans in development and on every release to stop regressions cheaply.
Fix automated findings before a manual audit, so experts spend paid time on what tools cannot judge.
Manually test the journeys that matter most: sign-up, sign-in, search, checkout, contact.
Treat Needs review results from tools as a manual testing to-do list.
Before claiming conformance or writing an ACR, do a full evaluation using a method such as W3C WCAG-EM.
Include people with disabilities in usability testing when you can.

Automated vs manual accessibility testing compared

Aspect	Automated testing	Manual testing
Who or what	Software rules, such as axe-core	Accessibility specialists using keyboards and assistive technology
Speed	Seconds per page	Hours per page or journey
Scale	Every page, every release	Representative pages and key journeys
Consistency	Same result every run	Depends on tester skill and method
Finds	Code-level, repeatable failures	Meaning, usability and task-level barriers
False positives	Few with good rule sets; uncertain cases flagged for review	Rare, but judgments can differ
Can confirm WCAG conformance	No	Yes, with a defined scope and method

Common Questions

Is automated accessibility testing enough?

No. It is an essential first layer, but many WCAG criteria need human judgment. Use it for speed and coverage, then test key journeys manually.

What percentage of accessibility issues can automated tools find?

Deque's study of real audits found about 57% of issues by volume. A GOV.UK test of 10 tools found the best one detected 37% of 143 deliberately varied barriers, and 29% were missed by every tool.

Can a website score 100 and still be inaccessible?

Yes. A perfect automated score means no rule the tool can check failed. Problems like misleading alt text, illogical focus order or confusing errors can remain.

How often should I run each kind of test?

Automated checks on every release and at least monthly. Manual audits at least once a year, and whenever a major redesign or new key journey ships.

Do I need a screen reader for manual testing?

For a full evaluation, yes. NVDA on Windows and VoiceOver on macOS and iOS are free and widely used for testing.

Are accessibility overlays a substitute for testing?

No. Overlays do not change the underlying code assistive technology relies on, and they do not replace either automated or manual testing.

Sources

Run a free accessibility score