DOJ Title II hits in 12 months. Cities quote $50K per audit. My scanner runs from $19/mo.

I spent the last six weeks building an accessibility scanner. Not because I'm an accessibility expert — I'm not — but because I went down a rabbit hole reading procurement RFPs, FTC consent orders, and ADA case law, and the more I read the more it looked like a category that was completely broken.

Here's what I found, what I built, and what I'd do differently if I had to start over.

The setup

Two things hit the accessibility-software market in 2025 that nobody outside the industry seems to have noticed.

One: the FTC fined accessiBe $1 million dollars in April 2025 for deceptive marketing. Their AI-overlay product had been sold for years on the promise that it could make any website "fully WCAG compliant" with one line of JavaScript. The consent order says, in plain English, that this was not true. The overlay applied cosmetic patches; it did not fix the underlying source code; the websites buying it were still sued under the ADA. (FTC v. accessiBe Ltd., 2025 consent order — public.)

Two: the U.S. Department of Justice finalised the Title II web-accessibility rule. Public entities (cities, counties, school districts, state agencies) with 50,000 or more residents must have their websites and mobile apps conformant with WCAG 2.1 AA by April 26, 2027. Smaller entities have until April 26, 2028. There are around 1,400 entities in the larger tier and 38,000 in the smaller. (28 CFR Part 35 — public.)

So you have:

• A category leader that just got fined for selling a product that didn't work,
• A federal deadline that creates demand for tens of thousands of buyers, and
• A meaningful private-litigation tail — research from Seyfarth Shaw shows around 22.6% of ADA Title III suits in the first half of 2025 named defendants who had an overlay product installed at the time of filing. The overlay didn't prevent the case; in some pleadings it was evidence of the deceptive-claim count.

If you're a city manager with a $5M general budget and a Title II deadline coming up, your options today are roughly: pay a consultancy $30-80K for a manual audit and a remediation plan, install an overlay and hope (no), or build it yourself.

I figured there had to be a fourth option.

What I built

AccessiScan crawls a public website, runs WCAG 2.1 AA conformance checks on every page it finds, and returns a per-criterion report. That part is table-stakes — the open-source axe-core library can do most of it. The interesting part is what happens after the scan.

For every violation it can repair, it generates a pull request against your repo with the actual fix code. Missing alt text gets a contextual alt= attribute. Empty buttons get an aria-label. Form fields without labels get <label> wrappers. Low-contrast text gets a token swap suggestion. The fix lands in a branch, with the source citation linked in the PR description, and your engineers review and merge.

It also exports a VPAT 2.5 mapped to WCAG 2.1 A and AA — which is the document procurement teams actually need when they're filling out a Title II compliance attestation or an RFP response. And it ships a GitHub Action that runs the same scan on every pull request, so you don't regress.

Pricing starts at $19/month for one site. The Agency tier with the GitHub Action template, white-label VPAT exports, and unlimited domains is $49/month. The Business tier adds Auto-Fix PRs against your repo, continuous monitoring, and the EU EAA + Section 508 pack — that's $299/month, the SLA-backed plan procurement teams ask about. Public entities and procurement teams get a 20% discount on the annual plan. The free tier runs a real scan against any URL with no signup; that's the one I'd link from a procurement RFP.

What I learned that changed the build

I'll save you the obvious lesson (overlays don't work) and skip to the three findings that actually surprised me.

1. The buyer is not the user. The person paying for accessibility software is almost never the person who has to use the report. The procurement officer wants a VPAT and a renewal contract. The engineer wants source-code diffs in a language their codebase already speaks (Tailwind classes, not generic CSS). The accessibility consultant wants a WCAG-criterion-level breakdown for the audit letter. I redesigned the report three times before I realised I needed three different report views, not one.

2. "Compliant" is not a binary, and customers know it. Every accessibility tool I evaluated marketed itself as a route to "100% compliance." The actual conversation procurement officers have with their counsel is about demonstrating good-faith effort and reducing legal exposure. That's a different product. AccessiScan reports a conformance score with explicit caveats about manual-test gaps (focus management, screen-reader narration on dynamic content) — and the procurement officers I talked to said that was the first scanner they could actually quote in a Title II attestation without their counsel rewriting it.

3. The auto-fix PR is the moat. Nine months ago I would have told you the moat was the scan engine. It isn't — the scan is solved. The moat is the part that takes a 2.4.4 Link Purpose violation, reads the surrounding JSX, generates an aria-label that fits the link's destination, and ships it as a clean diff. That requires reading code, not just running rules. It's the only piece I'd have a hard time rebuilding from scratch.

Where this goes wrong

I'm sharing this on the way up, not from a finished line. There are three things I haven't solved and they're worth flagging.

The hardest WCAG criteria are still manual. Anything involving keyboard focus, screen-reader narration, or dynamic-state announcement requires running the page in an assistive tech and listening. We catch the structural violations; we cannot catch a screen reader saying "button" when it should say "submit my application." For now we ship a checklist and a aria-live linter. Eventually I want to ship a manual-audit-as-a-service tier that pairs a human reviewer with the automated scan — but I haven't built it yet.

Overlays still convert. I've watched at least two municipal websites buy an accessiBe-style overlay after reading our comparison page. Lower trust in deep-tech procurement than I expected. Educational selling is necessary, not optional, and a free tool that just works on their actual URL is the only marketing that compounds.

The DOJ deadline is a forcing function but not a moat. Once 1,400 large public entities buy something, the second wave of 38,000 smaller entities is going to compress prices toward $9/mo per site. Whoever is best at distribution at the per-state level wins. I haven't started that conversation with state procurement co-ops yet.

Try it

If you've got a website you'd like a Title II conformance read on, the free scanner is here:

→ accessiscan.piposlab.com/free/wcag-scanner

Drop a URL, get a report in 60 seconds, no signup. If the report is useful and you want the auto-fix PRs and the VPAT, that's where the paid tier kicks in.

I'd genuinely love feedback from anyone in this thread who's been on either side of an accessibility procurement — buyer or vendor. The biggest open question I have is how the smaller-entity wave will source this; if you've worked with state-level procurement co-ops or municipal-association group buys, I'd love to hear what worked.

Six weeks of work, $19/mo, public deadline. The rest of the moat is execution.

— Alex (Pipo Labs)