Accessibility Testing Services: What They Actually Cover

Five different things get sold under this label, automated scans, manual review, assistive-tech testing, user testing, and regression testing, and most vendors only give you the first one.

What do accessibility testing services actually include?

A real accessibility testing service runs your site through several distinct layers, not one scan with a report attached. The layers are automated scanning, manual expert review against WCAG criteria, assistive-technology testing with a keyboard and a screen reader, user testing with people who actually rely on that technology day to day, and regression testing once a fix goes out. Each layer catches something the others don’t.

Plenty of vendors sell you the first layer and call it a testing service. You get a dashboard, a score, a list of flagged elements. That’s a scan, not testing. The distinction matters because a scan alone can’t confirm a keyboard trap, can’t judge whether link text makes sense in context, and can’t tell you whether a screen reader user could actually finish your checkout flow.

This article walks each layer on its own, then lines up testing services against an audit and against remediation, because those three words get used interchangeably and they shouldn’t be. If you want the audit process specifically, meaning the scoped, one-time engagement that produces a punch list, that’s covered in the website accessibility audit guide. If your organization already has 50 or more Ontario employees and needs the legal picture behind why any of this matters, start with the WCAG 2.0 AA explainer.

What do automated accessibility scans actually catch, and what do they miss?

Automated scans catch what a machine can verify against markup, contrast ratios, missing alt attributes, some ARIA mistakes, and they run in seconds. What they can’t catch is anything that needs a human to judge whether it actually works.

Here’s where the honest numbers get messy, and worth sitting with. Deque, the company behind the widely used axe testing engine, published its own Automated Accessibility Coverage Report after analyzing more than 13,000 pages and nearly 300,000 logged issues. Measured against WCAG 2.1 AA’s 50 success criteria, automated checks map to about 16 of them, roughly 30 percent, which lines up with the 30 to 40 percent range TestParty’s own breakdown cites (already covered in more depth in the accessibility audit guide). But measured a different way, by total volume of logged issues rather than by criteria, Deque’s same data shows automated tools catching around 57 percent.

Both numbers are real. They’re just measuring different things, and the gap between them is the whole debate. Deque’s own report flags the reason: the 57 percent figure is skewed heavily by color contrast, a single failure type automated tools detect near-perfectly and that shows up constantly on real sites. Strip contrast out and the volume-based number drops back toward the criteria-based one. Neither number tells you whether your specific site is fine. Both tell you the same underlying thing, a scan alone leaves somewhere between roughly 40 and 70 percent of what matters untested, depending how you count it.

What that gap actually contains: focus order that doesn’t match visual order, a modal that traps keyboard focus, alt text that’s technically present but useless, link text that says “click here” ten times on one page. None of that shows up red in a scanner. All of it blocks a real visitor.

Manual testing vs automated testing: what’s the real difference?

Automated testing runs a tool against your code. Manual testing is a trained person reading that same code, and operating the page, against the WCAG success criteria the tool can’t evaluate on its own. They’re not competing methods. A real testing engagement runs both, in that order, because the scan clears the easy findings fast so the manual pass can spend its time on what a machine genuinely can’t judge.

A manual tester checks things like whether a heading structure actually reflects the page’s real hierarchy, whether an error message on a form tells you what to fix or just turns the border red, whether an ARIA role someone added years ago is doing more harm than the plain HTML it replaced. None of that has a programmatic yes or no answer. It takes judgment, the kind that comes from having tested a lot of sites and knowing what a genuine barrier looks like versus a technically-passing edge case.

This is also the point where the vendor matters more than the tool. Two testers running the identical scanner on the identical page can hand back different manual findings, because manual review is a skill, not a checkbox. If a vendor’s pitch is entirely about which automated scanner they license, ask what the manual layer actually looks like, because that’s where the real work, and the real cost, lives.

How does assistive-technology testing work: screen readers, keyboard, and zoom?

Assistive-technology testing means a tester actually uses your site the way a disabled visitor would, unplugging the mouse, turning on a screen reader, and zooming the page, rather than reading the code from the outside. It’s the layer that catches the gap between “this markup looks correct” and “this actually works when someone uses it.”

Keyboard-only testing

The tester tabs through every page with no mouse: every menu, every form, every modal. Can you reach it? Can you operate it? Can you tell where focus currently sits? A missing focus outline, or a JavaScript widget that swallows the Tab key, fails here even when the underlying HTML looks fine on paper.

Screen reader testing

Real screen reader use skews toward a small set of tools. Per WebAIM’s most recent Screen Reader User Survey, JAWS and NVDA together account for roughly three-quarters of desktop screen reader use, with VoiceOver close behind at around 10 percent, while VoiceOver dominates mobile at over 70 percent. A serious testing engagement covers at least one desktop reader and VoiceOver on mobile, not every tool on the market, because thorough coverage of one tells you more than a shallow pass across five.

Zoom and text resize

The tester zooms the browser to 200 percent, the threshold WCAG 2.0 Level AA’s text-resize criterion actually requires, and checks that nothing clips, overlaps, or disappears. Some testing services go further and check reflow at 400 percent too, a WCAG 2.1 criterion. That’s a genuinely good extra check, but it sits above what AODA’s WCAG 2.0 AA baseline legally requires in Ontario, so don’t let a vendor imply 400 percent reflow is mandatory here when 200 percent resize is the actual legal bar.

Why test with people with disabilities, not just an expert?

An expert tester finds WCAG violations. A person who actually relies on assistive technology every day finds the friction that a technically-passing page still creates. Those are two different kinds of findings, and a testing service that only offers the first one is giving you half the picture.

The W3C’s own guidance on involving users in evaluating web accessibility draws exactly this line. Conformance testing tells you whether a page meets a written standard. Evaluating with real users, including people with disabilities and older users, surfaces usability issues that conformance testing alone never catches, because a page can technically pass every success criterion and still be exhausting to actually use. The W3C’s guidance also notes something practical, informal evaluations run throughout a project, a quick session with someone who uses a screen reader daily, tend to catch more real problems than one formal usability test bolted onto the end.

This layer is the one most testing services skip, because it’s slower to arrange and harder to standardize than running a scanner. Ask directly whether a vendor’s quote includes any user testing at all, or just expert-and-tool testing dressed up with that language.

What is regression testing, and why does it matter after a fix ships?

Regression testing means retesting the exact items a previous round flagged, after the fix goes live, to confirm the fix actually worked and didn’t break something else nearby. Skip it and you’re left attesting to a fix nobody verified.

It matters more than it sounds like it should, because accessibility fixes have a habit of creating new problems while solving old ones. A developer adds an ARIA label to quiet a scanner warning and accidentally makes a screen reader announce the wrong thing. A contrast fix on one button quietly breaks the hover state on three others that share the same CSS class. None of that is rare. It’s the normal cost of touching shared code, and it’s exactly why a testing report that ends at “here’s what’s wrong” without a path back to “here’s confirmation it’s fixed” leaves the job half done.

A properly scoped testing engagement builds retesting into the timeline from the start, not as a separate line item you have to ask for later. If a quote doesn’t mention retesting, ask what happens once fixes go out, because that’s usually where the real answer is “you’re on your own.”

Audit vs. testing services vs. remediation: how are they different?

These three words get used as if they’re interchangeable. They’re not, and buying one doesn’t hand you the other two for free.

In practice the three overlap. A good audit includes a manual and assistive-tech testing pass. A good remediation project includes retesting once fixes ship. The label on the invoice matters less than confirming, before you sign anything, which of these three you’re actually paying for.

How do you actually buy accessibility testing services?

Scope by template and component, not by page count, and ask five direct questions before you sign anything. Page count tells a vendor almost nothing about the real effort involved, because a ten-page brochure site and a ten-page site carrying a custom booking widget and a mega menu are not the same job. The AODA audit checklist covers the sampling logic in more depth if you want the full method.

Five questions separate a real quote from a scan dressed up as one.

• Does the quote include manual testing, or only an automated report?
• Which assistive technologies are actually used, and by whom, an in-house tester or a person who uses that technology daily?
• Is user testing with people with disabilities included, or available as an add-on?
• Is retesting after fixes ship included in the price, or billed separately later?
• What does the deliverable actually look like, a raw scanner export, a plain-English punch list, or a formal VPAT/ACR?

That last one matters if you’re selling into an enterprise or government buyer. The Information Technology Industry Council’s official VPAT is the standard template for documenting conformance against WCAG, Section 508, and EN 301 549, and a completed one is called an Accessibility Conformance Report. Most Ontario small and mid-size business sites don’t need a formal VPAT. If you sell software or services to a larger organization that does procurement reviews, ask specifically, because a vendor quoting a general small-business audit may not be quoting VPAT-grade documentation at all.

What deliverables should a testing engagement actually produce?

You should walk away with findings tied to specific WCAG criteria, evidence of how each layer was actually tested, and a clear next step, not a raw export from a scanning tool with your logo pasted on top.

A real deliverable set includes a prioritized list ranked by user impact rather than alphabetical WCAG clause number, a note on which assistive technology confirmed each manual and AT finding, and, if user testing was part of the scope, a summary of what actual participants ran into. If regression testing is included, you should also get a short re-test log once fixes land, confirming what was checked again and what passed.

One thing worth naming plainly. A dashboard score or a badge is not a deliverable in this sense, it’s a marketing artifact. If what you receive at the end can’t be traced back to specific WCAG success criteria and a specific test method, ask where that mapping is, because it’s the difference between something you can act on and something you can only display.

Can you run accessibility testing yourself, or do you need to hire it?

You can genuinely run the first two layers yourself on a small site. A free scanner and an afternoon spent tabbing through your own homepage with no mouse gets you real signal, and it costs nothing. Where DIY testing runs out of road is assistive-technology depth and user testing, both of which need either training you probably don’t have or actual participants you’d have to recruit and compensate.

On any serious build I’ve worked on, testing against real assistive technology was never optional. It happened before launch, as a release gate, not a nice-to-have squeezed in afterward. That standard doesn’t change for a smaller Ontario business site, only the scope does. If your organization is at or approaching the 50-employee AODA threshold, or you’re simply tired of guessing, a professional testing pass covering the manual and assistive-tech layers is worth the cost of getting it wrong once. The accessibility service covers exactly this, and a free scan is one message away at contact.

Where should you start?

Start with the free layer this week, an automated scan plus a five-minute keyboard tab-through of your own homepage, and see what it turns up. Most sites built on a stock theme were never tested this way, so don’t be surprised if it’s more than you expected.

From there, go deeper based on what you find. If you want the full audit process, meaning a scoped, one-time diagnostic with a punch list, that’s the accessibility audit guide. If you already know your site fails and need the code actually fixed, that’s AODA remediation. And if what you need is the standard itself explained plainly before either of those, start with WCAG 2.0 AA in plain English.

Frequently asked questions

Quick, direct answers to what business owners ask most about accessibility testing services.

What’s included in accessibility testing services?

A real engagement layers automated scanning, manual expert review against WCAG criteria, assistive-technology testing with a keyboard and screen reader, often user testing with people with disabilities, and regression testing after fixes ship. Many vendors only deliver the first layer.

What percentage of accessibility issues do automated tools catch?

It depends how you measure it. the widely quoted 20 to 30 percent of WCAG criteria is an industry estimate that Deque’s own coverage report disputes; by issue volume Deque measures automated coverage at 57.38 percent, a figure skewed heavily by how often colour contrast alone gets flagged.

What’s the difference between accessibility testing and an accessibility audit?

Testing is the layered process, automated, manual, assistive-tech, sometimes user testing. An audit is a scoped, one-time diagnostic engagement that typically includes several of those layers and produces a prioritized report. The terms overlap in practice more than vendors’ marketing suggests.

Do I need to test with real people with disabilities, or is expert review enough?

Expert review finds WCAG violations. User testing with people who actually rely on assistive technology finds usability friction a conformance check alone misses, per the W3C’s own guidance on involving users. The two are genuinely different, not interchangeable.

What is a VPAT, and do I need one?

A VPAT (Voluntary Product Accessibility Template) is the standard document used to report WCAG, Section 508, and EN 301 549 conformance, mainly for enterprise and government procurement. Most small Ontario business sites don’t need one unless a larger buyer’s procurement process specifically requires it.

Does accessibility testing make my website AODA compliant?

No. Testing documents where you stand and verifies fixes once they ship. Compliance comes from actually fixing what testing finds in the code, not from the testing report itself.