Manual accessibility testing is a person evaluating a website with a keyboard, assistive technologies and their own judgment. Automated accessibility testing is software checking pages against rules it can verify in code. Automated testing covers every page quickly but finds only the barriers a machine can detect. Manual testing finds the barriers that depend on meaning and experience but can only cover a sample of pages. Most organizations need both, combined deliberately rather than by default.
The gap between the two is large. When the UK Government Digital Service ran 13 automated tools against a page containing 142 deliberate barriers, the best tool found 40% of them (GDS accessibility tool audit). Tools have improved since, but the kinds of barriers they miss have stayed much the same.
Manual vs. automated accessibility testing at a glance
| Manual testing | Automated testing | |
|---|---|---|
| What it finds | Barriers that need judgment: whether alt text conveys an image’s purpose, whether link text makes sense out of context, whether focus order follows the page’s logic, whether error messages explain the fix | Rule-based failures visible in code: missing alt attributes and form labels, empty links and buttons, contrast between flat colors, missing page language, duplicate IDs |
| Assistive technology | Tests how pages behave with screen readers, magnification and voice recognition software | Can’t operate assistive technology, though it can check the code that assistive technology relies on |
| Scale | A sample: key templates, components and complete user journeys | Every page, every time it runs |
| Speed and repeatability | Hours to days per scope, and results depend on the tester | Minutes, with consistent results run after run |
| Expertise needed | Trained testers who know WCAG, disabilities and assistive technology | Little to run, but real knowledge to interpret results and fix issues |
| Where it fits | Before major releases, after significant design or code changes, and on a schedule for key journeys | During development, in build pipelines and as continuous monitoring of live content |
| What drives cost | Tester time, which grows with scope | Setup and licensing, plus the time spent triaging results |
When each is the right choice
Lead with automated testing when the problem is scale: hundreds of sites, thousands of pages, many editors publishing every day. No team can manually review content at that rate, and automated monitoring catches regressions the day they appear.
Lead with manual testing when the question is whether something actually works for people: a new checkout, a redesigned navigation, a custom widget, a form that decides whether someone can apply for a service. Automated checks can pass a page that a screen reader user still can’t complete. For a step-by-step method, see how to perform manual accessibility testing.
What is a hybrid approach to accessibility testing?
A hybrid approach assigns each kind of check to the method that does it best. Automated testing runs continuously across the whole estate and handles every rule a machine can verify. Manual testing goes deep on the templates, components and journeys where judgment matters, and on anything automation flags as uncertain. The two feed each other: automated results show where manual effort is most needed, and manual findings show which patterns to fix at the template level so they stop recurring.
Hybrid isn’t a compromise between the two methods. It’s the only way to get both coverage and accuracy, because neither method can supply the other’s strength.
Assisted testing
Assisted testing is a semi-automated method in which software flags a potential issue and asks a person a series of questions to decide whether it’s a real failure. It combines the reach of automated testing with human judgment on the cases software can’t settle alone, and it doesn’t require an accessibility specialist to answer every question. With basic technical knowledge, more people on a team can contribute to testing while learning how accessibility issues arise.
How to choose the right mix for your organization
The right balance depends less on preference than on the shape of your digital estate. Weigh these factors:
- How many properties you manage. The more sites and pages, the more the program depends on automated coverage, and the more carefully the manual sample has to be chosen.
- How decentralized publishing is. When many editors across departments publish independently, content-level issues appear constantly, and only continuous automated checks keep pace.
- Your CMS and templates. Barriers built into a shared template repeat on every page that uses it, so manual testing of templates pays off across the estate. An authoring environment that is itself hard to use accessibly makes every editor’s job harder.
- In-house expertise. Teams with trained accessibility testers can run manual testing themselves. Teams without them rely more on automated results and external testers.
- Regulatory exposure. Organizations with legal or contractual accessibility obligations benefit from documented results from both methods. Those obligations usually reference WCAG, and judging conformance takes checks automation can’t perform.
How to build testing into your workflow
Accessibility testing works best as part of the routine work of web, content, design and QA teams, not as a separate project at the end. Bring those teams in from the start, since they will apply accessible practices every day.
Catch issues before production
Require that new code passes automated accessibility checks before it’s considered done, whether in a developer’s browser, with a tool such as Siteimprove’s accessibility browser extension, or as a step in the build pipeline. Fixing an issue before release is far cheaper than finding it on hundreds of live pages. Then review new templates and components manually, including with a keyboard-only pass and a screen reader, before they go live.
Scale across sites and editors
Once content is live, automated monitoring checks what editors publish every day and shows which issues recur across sites. Use those patterns to choose where manual testing goes next, and fix recurring problems at the source: the template, the component or the editor guidance.
Follow up with routine manual and user testing
Schedule manual reviews of your most important journeys at regular intervals, and run user testing with people with disabilities. Their experience of your site will reveal issues that even trained testers overlook. Before a user testing session:
- Have a clear scope and goals for what conclusions you hope to gain.
- Prepare test materials and ensure functioning assistive tech (e.g., screen reading software).
- Create a comfortable and quiet environment to ensure there are no interruptions.
- Carefully observe and consider all feedback. Don’t assume feedback from one person with a disability applies to all people with disabilities.
- Consider recording testing sessions to help you track and report your progress.
Tools for each approach
Automated testing tools fall into three groups: site-wide scanning and monitoring that checks every page on a schedule, browser extensions that check one page at a time, and linters and test libraries that run in a build pipeline. Free tools such as Google’s Lighthouse and WebAIM’s WAVE are a common starting point for checking individual pages.
Manual testing relies on the tools people with disabilities use: screen readers such as NVDA, JAWS and VoiceOver, screen magnification, voice recognition software and the keyboard itself, plus a color contrast checker for text over images and gradients. A full accessibility audit combines both sets of tools with a structured review against WCAG.
In-house testers or external testing services?
An in-house team of manual testers can work inside design and development, catch issues early and build accessibility knowledge across the organization. Building one takes organization-wide buy-in and budget. External testers bring independent review and depth with assistive technology, which is useful for formal audits, high-stakes releases or when you need a third-party evaluation on record. Many organizations combine the two, using in-house testing for day-to-day work and manual testing services for periodic independent review.
Frequently asked questions
Should I prioritize manual or automated accessibility testing?
Neither alone. Start with automated testing for coverage, since it shows the scale of the problem across every page, then direct manual testing at the templates and journeys that matter most. Prioritizing one method doesn’t mean skipping the other.
Can automated testing alone show that a site conforms to WCAG?
No. Many WCAG success criteria depend on human judgment, such as whether alt text is meaningful or whether instructions make sense, and conformance applies to full pages and complete processes. Automated results are evidence toward conformance, not proof of it.
How can I integrate manual testing into my workflow?
Tie it to the moments when barriers are most likely to appear: new templates and components before launch, significant design or code changes, and a scheduled review of key journeys. Use automated results to decide where each round of manual testing goes.
What are the benefits of automated accessibility testing?
Speed, coverage and consistency. It checks every page, repeats the same checks every time and catches regressions as soon as content changes. See automated accessibility testing for more on how it works and where it stops.
How does AI-assisted testing fit in?
AI can extend what automated tools flag, for example by suggesting alt text or highlighting likely problems in complex components. Its output still needs human review, because the judgment calls that make manual testing necessary don’t go away when software makes a first guess.
