The accessibility consultant vs scanner question has a short answer: use a scanner for anything that repeats, and hire a consultant for anything that needs judgement. A scanner is cheap per check, runs on every deploy and never gets bored, but it only sees what can be decided from markup and rendered styles. A consultant is expensive per hour and sees everything else: whether your custom combobox works with a screen reader, whether an error message makes sense, whether a checkout can be finished at 200% zoom on a phone. The W3C says it directly: "Knowledgeable human evaluation is required to determine if a site is accessible" (W3C WAI). So the real decision is not which one to pick. It is which one you need first, and how to stop paying a person to re-check what a machine already caught. If you have never had a human review, start with one. If you have, a scanner keeps that result from going stale, and the consultant's next visit can go straight to the hard parts.
What does a scanner actually do that a consultant doesn't?
It checks the same rules on every page, every time, without forgetting any of them.
Deque's study of more than 2,000 audits, covering over 13,000 pages and nearly 300,000 issues, found automated testing covered about 57% of issues by volume (Deque). Measured by WCAG success criteria rather than by issue count, the share is much lower, nearer 30%. We quote the whole range, roughly 30 to 57%, because both numbers are true and they measure different things. The volume figure is high because the most common failures are the mechanical ones: missing alt attributes, low contrast, inputs with no label, empty links, a missing lang on <html>.
A person can find all of those too. They just shouldn't have to. Paying a consultant to report that button.icon-close has no accessible name, on 40 templates, is a poor use of their day rate. A scanner also does things a person structurally can't:
- It runs on every pull request, so a regression is caught before a customer sees it.
- It covers hundreds or thousands of URLs, where a manual review samples a dozen.
- It gives you a dated history, which is the evidence you need when someone asks what you knew and when.
That last point matters more than it looks. Under the EAA, Article 13(3) of Directive (EU) 2019/882 requires service providers to have "procedures in place so that the provision of services remains in conformity" with the accessibility requirements (EUR-Lex). One report from a consultant last spring is a snapshot. A procedure is something that keeps running.
What does a consultant catch that a scanner never will?
Meaning, behaviour and context. The W3C's guidance on choosing tools is blunt: evaluation tools "can not determine accessibility, they can only assist in doing so", and "Human judgement is required" (W3C WAI).
Some concrete examples of what lands on the human side of the line:
- A scanner confirms an image has
alt. It can't tell you the text says "hero-final-v3.jpg" or describes the wrong thing. - It can confirm a dialog has
role="dialog". It won't notice that closing it sends focus to the top of the page instead of the button that opened it. - It can check that an error message exists in the DOM. Whether a screen reader announces it, and whether a person understands what to fix, takes someone listening.
- It can't judge whether your heading structure matches how the page actually reads, or whether a drag-and-drop interaction has a usable single-pointer alternative.
A good consultant also knows which of your 300 findings come from one broken component, which block a task and which are cosmetic. That triage is often worth more than the findings list. We go through what a thorough review covers in what a real accessibility audit includes.
When should you hire an accessibility consultant?
When the question needs judgement and nobody on your team has the depth to answer it. In practice, these are the common triggers:
- You have never had a human review. Without one you don't know your baseline, and a scanner's green dashboard tells you nothing about the criteria it can't evaluate.
- You need to sign a document. A conformance report, a VPAT, an EN 301 549 Annex C table or an accessibility statement makes claims per criterion. Someone has to have actually tested each one.
- You're shipping custom interactive components. Date pickers, comboboxes, data grids and drag interfaces are where scanners are weakest and where users get stuck.
- You're redesigning. An hour of review on the design system before it ships beats a week of remediation after.
- Your team needs training, not just findings. A consultant who pairs with your developers on two real bugs leaves more behind than a 90-page PDF.
WCAG-EM 2.0, the W3C's evaluation methodology published as a Group Note in July 2026, assumes evaluators "have solid understanding of how to evaluate content using WCAG 2" and allows for "a team of evaluators with collective expertise" when one person doesn't cover everything (W3C). That's a fair description of what you're buying. Before you sign, ask which assistive technologies they test with and for a sample report.
One more thing a consultant can arrange that a scanner can't: testing with disabled people. The W3C notes that evaluating with users "identifies usability issues that are not discovered by conformance evaluation alone" (W3C WAI).
When is a scanner enough on its own?
Rarely for a first assessment, and often between assessments.
If your site is a set of content pages built on a well-tested theme, changes weekly, and you've had one solid human review, continuous scanning plus a light manual check on your main journey can carry you for a long time. The scanner catches the new image without alt text that marketing published on Thursday. The manual check covers the parts it can't.
Where a scanner alone falls short is any claim of conformance. Automation finds issues. Full conformance needs human review, and there's no configuration setting that changes that. If a dashboard shows a high score, ask which criteria it never evaluated and who checked those.
The legal texts don't force you to hire outside help, which surprises some teams. For products, the EAA's Annex IV describes "internal production control", a procedure where the manufacturer "ensures and declares on its sole responsibility" that the product meets the requirements (EUR-Lex). Nothing in the Act requires a third-party auditor. What it does require is that the assessment is real. Whether your own team can do that work, or you bring someone in, depends on the skills you have in-house. US teams working under the ADA are in a similar place: the law sets the obligation and leaves the method to you.
Accessibility consultant vs scanner: how do the costs compare?
They're priced on different things, so a direct comparison misleads. A scanner is priced per site, page or scan, and the cost per check falls as you scan more. A consultant is priced per day or per engagement, and the cost scales with the number of templates and journeys in scope.
| Scanner | Consultant | |
|---|---|---|
| What you pay for | Coverage and repetition | Judgement and expertise |
| Cost drivers | Pages, sites, scan frequency | Templates, journeys, AT combinations |
| Best at | Mechanical failures, regressions, evidence over time | Keyboard and screen reader behaviour, meaning, triage |
| Blind spots | Roughly half or more of the criteria, depending on how you count | Anything outside the sample, anything shipped after the visit |
| Cadence | Every deploy, nightly or weekly | Once a year, or at a redesign or procurement |
The cheapest setup I've seen work is not "less consultant". It's a scoped consultant. If your scanner already covers contrast, labels, alt presence and ARIA validity across 400 pages, the consultant shouldn't re-check those by hand on 12. Point them at keyboard operability, focus management, the custom components and the two or three journeys that earn you money. You buy fewer days and get sharper findings. Our posts on remediation cost and manual vs automated testing go deeper on where that money goes.
How do you use both without paying twice?
Run the scanner first, then send the consultant its results.
Here's the order that works for most product teams:
- Scan your real journeys, including the logged-in ones: signup, checkout, account settings, the main task in your app. Not just the homepage.
- Fix the mechanical failures yourself. Most are one-line changes, and many share a single root cause in a shared component.
- Bring in the consultant with the scan report and a list of what's out of scope because automation already covers it.
- Turn their findings into rules where you can. A focus-order bug can't be auto-detected in general, but "this dialog must return focus to its trigger" can become a test in your own suite.
- Keep scanning. Book the next human review for the next redesign or in a year, whichever comes first.
My opinion, plainly: a scanner that has never been checked against a human review is a comfort blanket. The number goes up, the team relaxes, and the criteria it couldn't evaluate stay broken. We built our scanner to say what it can't decide and leave those items open instead of quietly passing them, because that's the only kind of report worth handing to a consultant, or to a regulator.
Frequently asked questions
Can an accessibility scanner replace a consultant?
No. A scanner catches roughly 30 to 57% of issues depending on how you count, and the rest, such as meaningful alt text, focus management and screen reader behaviour on custom components, needs a person. A scanner reduces how much consultant time you need. It doesn't remove the need.
Do I need an outside consultant, or can my own team do the manual review?
Your own team can do it if they have the skills. The EAA lets manufacturers assess their own products under Annex IV, and WCAG-EM assumes a solid understanding of WCAG evaluation rather than any particular credential. If nobody in-house has tested with a screen reader before, bring someone in for the first round and have them train your team.
How often should we bring in an accessibility consultant?
Usually once a year for a product under active development, plus at any major redesign or before you sign a conformance report. Continuous scanning in between keeps the result from going stale.
What should I give a consultant before they start?
Give them your latest scan results, the list of journeys that matter most, and the custom components you're least sure about. That lets them skip what automation already covers and spend their time on the parts that need judgement.
Start with what a scanner can tell you
Before you price a consultant, find out what the machine-checkable layer looks like. Run a free scan on your most important journey, then work through the WCAG checklist to see which items still need a person. The gap between the two lists is the scope you'd hand a consultant.
Pavel Charkasau, founder, wcagc.com. Last updated 8 November 2026.
Sources
- Evaluating Web Accessibility Overview, W3C WAI — updated 12 August 2026; "Knowledgeable human evaluation is required to determine if a site is accessible." Accessed 8 November 2026.
- Selecting Web Accessibility Evaluation Tools, W3C WAI — updated 13 May 2024; "Tools cannot check all accessibility aspects automatically. Human judgement is required"; tools "can not determine accessibility, they can only assist in doing so." Accessed 8 November 2026.
- Involving Users in Evaluating Web Accessibility, W3C WAI — updated 30 April 2024; evaluating with users "identifies usability issues that are not discovered by conformance evaluation alone"; avoid assuming one person's input applies to all people with disabilities. Accessed 8 November 2026.
- Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 2.0, W3C — W3C Group Note, 23 July 2026; users are assumed to "have solid understanding of how to evaluate content using WCAG 2"; evaluation by "a team of evaluators with collective expertise"; most checks are not fully automatable. Accessed 8 November 2026.
- Automated testing study identifies 57% of digital accessibility issues, Deque — 10 March 2021; more than 2,000 audits, over 13,000 pages, nearly 300,000 issues; about 57% of issues covered by automated testing, measured by volume. Accessed 8 November 2026.
- Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — Article 13(3) on procedures so services remain in conformity; Annex IV, internal production control, where the manufacturer "ensures and declares on its sole responsibility" that the product meets the requirements. Accessed 8 November 2026.