Skip to content
wcagc
←Back to blog
agenciesscannerWCAGEN 301 549

How to choose an accessibility scanner for an agency

How agencies should pick an accessibility scanner: authenticated scans, WCAG and EN 301 549 mapping, honest coverage, and client-ready evidence.

P

Pavel Charkasau

For an agency, the right accessibility scanner is the one whose output you can hand to a client and defend in a meeting. That narrows the field fast. You need a tool that scans the pages your clients actually ship, including the ones behind a login, maps each finding to the standard the client is held to, and states plainly what it did not check. A raw issue count doesn't survive a client asking "so are we compliant?" The honest answer is always some version of "here's what the scan found, and here's what still needs a person with a screen reader," and your scanner should make that answer easy to give. This guide walks through what to weigh when you run accessibility across a portfolio of client sites rather than one of your own: authenticated and full-journey scans, standards mapping instead of a vanity score, honest coverage, evidence that holds up at handover, and a workspace built for more than a single project.

What should an agency look for in an accessibility scanner?

The W3C's guidance on selecting evaluation tools lists the features worth weighing: which technologies the tool checks (HTML, WAI-ARIA, PDF), whether its scope is a "single page" or "entire groups of related pages", whether it can reach password-restricted content, and which guidelines it tests against (W3C WAI). That is the right checklist to start from. For an agency, a few of those items carry more weight than the rest, and two more matter that the W3C list doesn't stress, because that page is written for a single site owner, not a shop running twenty accounts.

Here is the short version before the detail:

  • It scans real pages, including the ones behind a login.
  • It ties each finding to a named standard, not a single score.
  • It is honest that automation catches roughly 30–57% of issues.
  • Its output reads as evidence a client can keep.
  • One workspace holds every client, on predictable pricing.
  • It drops into the pipeline your developers already use.

Can it scan the pages your clients actually ship?

Most real barriers live where the automated crawlers of a cheap tool never go: the logged-in dashboard, the multi-step checkout, the onboarding wizard. A homepage scan tells you about the marketing site. It tells you almost nothing about the application your client's customers pay to use.

So the first question is scope. The W3C draws the same line, separating tools that check a single page from those that check groups of related pages, and calling out whether a tool can reach "password-restricted content" at all (W3C WAI). For agency work you want both: full-site crawls for breadth, and authenticated or scripted journey scans for the flows that matter. If a prospective client sells anything, ask the scanner to test the path from product page to confirmed order while signed in. That single run usually finds more than the whole rest of the marketing site combined. You can try this on a live page with a free scan before you commit to anything.

Does it map findings to WCAG and EN 301 549, or just give a score?

A score out of 100 is a number you cannot defend. A client will ask what standard it measures against, and "our tool's proprietary index" is not an answer that survives procurement.

Tie each finding to the law your client is actually held to. In the EU that is EN 301 549, which incorporates WCAG 2.1 Level AA for the web and gives the EAA its presumption of conformity. In the US it is WCAG 2.1 AA as applied under the ADA and Section 508. A finding that reads "image has no text alternative — WCAG 1.1.1" with the element and selector is something a developer can fix and a lawyer can file. "Accessibility score: 82" is neither. When a scanner speaks in success-criterion numbers, you can hand a client the WCAG checklist and show exactly which rows the scan covered and which still need a manual pass.

Is it honest about what a scan cannot catch?

This is the feature agencies underrate, and it is the one that protects your reputation. No scanner finds everything. Deque's study of more than 2,000 audits put automated coverage near 57% of issues by volume, well above the older 20–30% benchmark based on how many success criteria a tool can even evaluate (Deque). The W3C states the limit plainly: tools "can not determine accessibility, they can only assist in doing so" (W3C WAI). The rest, keyboard traps, focus order that makes no sense, a screen-reader announcement that says "button button", needs a human.

Here is the one opinion I will state plainly, as the person whose name is on this post: a tool that promises to make a site compliant on its own is a liability you are reselling to your client. The US Federal Trade Commission made that concrete in April 2025, ordering the overlay vendor accessiBe to pay $1 million and barring it from claiming its automated product can make a website WCAG-compliant without evidence (FTC). If you attach your agency's name to that promise, you inherit the exposure. Pick a scanner that tells you where it stops.

Will the report hold up at client handover?

An agency's deliverable is not a scan. It is evidence a client can keep, show an auditor, and act on after you have moved to the next project. Judge the output by whether it survives without you in the room.

Three things make it survive. First, findings should stay attached to a saved site with a history, so a re-scan after a fix shows the delta rather than a fresh unrelated list. Second, the manual work should have a home: a checklist of the criteria a scan can't judge, marked off by whoever did the keyboard-and-screen-reader pass. Third, the paperwork. Under the EAA a client has to publish an accessibility statement that documents their real level of conformance, known gaps, and a feedback contact. A scanner that turns actual results into an honest draft, through something like an accessibility statement generator, saves you writing it by hand and keeps the claim truthful. What none of this should include is a certificate or a badge that says the work is done. That claim is exactly what the FTC fined.

How does it handle a whole client portfolio?

Everything above assumes one site. An agency runs many, and that changes the shortlist.

Look for a single workspace that holds a client portfolio, with team seats for the people doing the work, so findings don't scatter across personal logins. Watch the pricing model closely: per-scan or traffic-based billing punishes you for doing thorough work, while a flat per-organization price lets you scan as often as a client needs. Our own agency plan is built on that shape, one workspace across a set of client sites at a flat price, precisely because per-scan meters make agencies scan less. Beyond that, the scanner should fit the pipeline your developers already use: a check that runs in CI so a regression fails the build before it ships, issue sync so findings land in the client's tracker, and scheduled re-scans so a site that passed in March doesn't quietly drift by June. If you are weighing us against a widget vendor, the alternatives hub holds the same line for each one.

Frequently asked questions

What is the most important feature in an accessibility scanner for an agency?

The ability to scan real pages, including logged-in flows, and to map each finding to a named WCAG success criterion. An agency's deliverable has to survive a client asking "compliant against what?", so standards mapping and authenticated coverage matter more than a large raw issue count or a single score.

Can an accessibility scanner make my client's site compliant?

No. A scanner finds the machine-detectable issues, which is roughly 30–57% of the total, and full conformance also needs manual testing with a keyboard and a screen reader (Deque). The W3C is explicit that tools can only assist in determining accessibility, not determine it (W3C WAI). Any tool that claims otherwise is repeating the mistake the FTC fined.

Should an agency use an accessibility overlay for clients?

Reselling an overlay puts your agency's name on a promise the FTC has already ruled deceptive when accessiBe made it (FTC). An overlay patches the page in the browser and leaves the client's code unfixed, so the barrier and the liability stay. A code-first scanner reports the issue so the client's developers fix it in source.

How many client sites should one accessibility scanner cover?

Enough to hold your whole portfolio in one workspace without per-site friction, and priced so you are not charged per scan. Count the client sites you manage today, add the ones you expect this year, and check that the plan covers that without a traffic surcharge that penalizes thorough scanning.

Does an agency scanner need to test logged-in pages?

Yes, for most clients. The barriers that get complaints tend to live in checkout, onboarding, and account areas that sit behind a login. The W3C flags whether a tool can reach password-restricted content as a selection feature (W3C WAI); for agencies it is close to mandatory.

See what a scan actually returns

The fastest way to judge a scanner is to point it at a page you know. Run a free scan on a client's checkout or dashboard, read the findings mapped to WCAG success criteria with the exact selectors, and see what the report would look like at handover. If it reads as evidence you could defend in a client meeting, it is the kind of tool an agency can build on. If it reads as a score and a badge, keep looking.

Written by Pavel Charkasau, founder of wcagc.com. Last updated 26 July 2026.

Sources