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

Source: https://accessibilityscore.in/automated-vs-manual-accessibility-testing
Last reviewed: 2026-10-16 by the HalfAccessible accessibility team

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.

## 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

1. [Deque: Automated testing coverage study](https://www.deque.com/automated-accessibility-testing-coverage/)
2. [GOV.UK Accessibility blog: What we found when we tested tools on the world's least-accessible webpage (2017)](https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/)
3. [WebAIM: The WebAIM Million, 2026 report](https://webaim.org/projects/million/)
4. [W3C WAI: Selecting web accessibility evaluation tools](https://www.w3.org/WAI/test-evaluate/tools/selecting/)
5. [W3C WAI: WCAG-EM conformance evaluation methodology](https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/)

Run a free accessibility score: https://accessibilityscore.in