Automated vs Manual Accessibility Testing: Where Each Fits
What automated accessibility testing catches, what needs a human, and how to combine both into a repeatable process that keeps your website WCAG compliant.
Table of contents
Accessibility teams often frame testing as a choice: buy a tool or hire an auditor. In practice you need both. Automated testing gives you coverage and speed. Manual testing gives you judgment. The skill is knowing which questions each one can answer, an approach the W3C’s Evaluating Web Accessibility Overview also recommends.
What Automated Testing Does Well
An automated website accessibility checker reads your page’s code and applies rules that have a clear right or wrong answer, such as the open-source axe-core rules. It excels at:
- Scale. Scanning thousands of pages in minutes, on a schedule.
- Consistency. Applying the same rule the same way every time.
- Regression detection. Noticing when a deploy removes a label or breaks contrast.
- Objective failures. Missing alt attributes, empty buttons, missing page language, unlabeled inputs, duplicate IDs referenced by ARIA, and contrast ratios below threshold.
These are also the barriers most often cited in legal complaints, which is why automated scanning is the foundation of any program.
What Only a Person Can Judge
Automated rules cannot understand meaning, intent or experience. A human tester needs to answer questions like:
- Is the alt text accurate? A tool can see alt=“chart”. Only a person can say it should describe the trend the chart shows.
- Is the focus order logical? A tool can confirm elements are focusable. A person can tell that focus jumps from the header to the footer and back.
- Do error messages help? “Invalid input” technically identifies an error. “Enter a date in the format MM/DD/YYYY” helps someone fix it.
- Are captions correct? A tool can detect a caption track. It cannot tell if the captions match the dialogue.
- Does the page work with a screen reader? Real assistive technology reveals issues with live regions, custom widgets and dynamic content.
- Does content reflow at 400 percent zoom? This needs a person looking at the layout.
A Side-by-Side Comparison
| Question | Automated | Manual |
|---|---|---|
| Does every image have an alt attribute? | Yes | Yes |
| Is the alt text meaningful? | No | Yes |
| Does text meet 4.5:1 contrast? | Yes, for most text | Yes, including text on images |
| Can every control be reached by keyboard? | Partly | Yes |
| Is focus order logical? | No | Yes |
| Do custom widgets announce state changes? | Partly | Yes |
| Are captions accurate? | No | Yes |
| Can it run on every page, every day? | Yes | No |
A Process That Combines Both
The most effective programs we see follow a simple loop.
1. Scan everything automatically. Crawl the whole domain and fix the objective failures first. They are fast to fix and high impact. Continuous monitoring, included in all AccessBell plans, keeps them from coming back.
2. Manually test your templates, not every page. Most sites are built from a limited set of templates: home, listing, detail, form, checkout, article. Manually test each template once with a keyboard and a screen reader. A fix to the template fixes every page built on it.
3. Manually test critical journeys. Sign up, log in, search, add to cart, check out, contact. Complete each journey using only a keyboard, then with NVDA, JAWS or VoiceOver.
4. Test new components before release. Add accessibility acceptance criteria to your definition of done. It is far cheaper to catch a keyboard trap in review than in production.
5. Listen to users. An accessibility statement with a clear feedback channel surfaces barriers that neither tools nor auditors anticipated.
Where AI-Assisted Fixes Fit
Newer tools, including ours, can suggest code fixes for common failures, such as a label for an unlabeled input or alt text for an image. Suggestions speed up remediation, but they should always be reviewed by a person who understands the content. A suggested alt text is a draft, not a decision.
How Often to Test
- Automated scans: at least weekly, and after every major deploy
- Template reviews: whenever a template or design system component changes
- Full manual audit: annually, or before a major launch or procurement review
The Takeaway
Automated testing tells you what is broken across your whole site, every day. Manual testing tells you whether your site actually works for people. Use automation for coverage and people for judgment, and you will find more issues, fix them faster and keep them fixed.
Start with the automated layer: run a free scan and use the results as your first remediation list. For a structured list of what to check by hand, see our WCAG 2.2 checklist. To record manual results, use our free WCAG 2 AA checklist spreadsheet.
