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)
This is one of the clearest examples I’ve seen recently of “regulation-driven software demand” being spotted early instead of reacted to late.
Most founders chase trends.
This founder chased enforcement mechanics.
That’s a very different lens
@amarionfred — thanks, the regulation-driven framing is the right lens, but the thing I had to unlearn building this is that enforcement mechanics ≠ enforcement timing. The Title II deadline is April 26, 2027, but the procurement window is now: RFPs going out in Q3 2026 for FY27 budgets, with counsel review cycles 6-12 months ahead of the deadline. So the curve isn't a spike on the deadline — it's a long tail of decision-makers locking in tools 12-18 months ahead.
The harder unlearn: regulators won't be the buyer. Compliance officers, city attorneys, and procurement co-ops will. They want defensibility (signed scan reports, VPAT 2.5 exports, audit trail) more than they want technical breadth. That's where the wedge is for any tool that wants to ride the Title II curve: be the artifact a counsel can point at, not the tool engineers prefer.
Curious which enforcement curves you've been tracking — I'd love to compare notes.
Merc — yes, I'd genuinely appreciate that intro. State-level procurement co-ops are exactly the buying pattern I've been trying to map: the multi-jurisdiction sourcing vehicles (NASPO, MHEC, WSCA, etc.) let smaller cities and counties piggy-back on a contract a larger entity already vetted. That's the channel I keep hearing about second-hand but haven't been inside.
The questions I'm trying to answer: (1) what's the typical RFP cycle for digital-accessibility tools — single procurement or buried inside a larger website-services contract? (2) how do smaller entities discover what's already on a co-op contract — is there a registry, or is it word-of-mouth through their state IT office? (3) what's the realistic price ceiling per-site for a co-op-vehicle tool vs an enterprise direct contract?
If those folks are open to a 20-minute call any time in the next two weeks, my email is [email protected]. Happy to share what AccessiScan actually does (and what it can't do) before they spend any time on it.
It sounds like you're really digging into the procurement process, which is notoriously tricky. I actually know a few state-level procurement co-op folks who might be happy to answer your questions about how smaller entities source software solutions.
This is one of those posts that quietly shows how real-world problems often sit in the gap between policy, tooling, and what people actually do.
What stands out is how clearly you mapped the ecosystem, not just accessibility is important, but the incentives: legal pressure, procurement behavior, and the failure of existing solutions like overlays.
The interesting part isn’t even the scanner itself, it’s the shift from checking compliance to generating actionable fixes in code and procurement artifacts. That’s a very different product mindset.
Also, the auto-fix pull request angle is genuinely the part that feels most defensible long term. Scanning is easy to copy. Changing code safely in context is where things get hard.
The nuance about compliance not being binary is also spot on. Most tools miss that procurement buyers don’t want perfection, they want defensible evidence and reduced risk.
Curious how you’re thinking about trust here, because in this space distribution usually depends as much on credibility as on product quality
Trust is the right thing to ask about, because the credibility loop is what makes a $19/mo scanner viable in a category where buyers are paying $40-80K to consultants for the same artifact. Four levers I'm working in parallel:
Source-cited claims, no exceptions. Every public claim on AccessiScan links the underlying source: FTC v. accessiBe is the consent order PDF, the 2027 deadline cites 28 CFR Part 35, the 22.6% overlay-defendant stat cites Seyfarth Shaw's H1 2025 research letter. If a procurement officer's counsel can't pull the citation in 30 seconds, the claim isn't on the site.
Honesty about what the scanner doesn't catch. The VPAT export has an explicit "manual testing required" section listing focus management, screen-reader narration on dynamic content, and color-only state signals. That paragraph reduces sales conversion ~15% in my early data — and triples the rate of procurement counsel approving the document without revisions. Net positive.
Open methodology on the auto-fix engine. Each generated PR comments cite the WCAG criterion ID + the source-code line that triggered it + a 5-file context summary the engine read. A reviewer can audit the bot's reasoning, not just its output. That's the structural answer to "how do I trust an LLM patching my codebase."
Channel credibility via accessibility consultants. The next phase of outreach is the Deque / TPGi / Level Access universe — not as competitors but as channel partners. A Level Access consultant who recommends AccessiScan to a client transfers their decade of credibility in a single sentence.
Pricing the scanner low enough to skip the procurement-by-committee path is intentional too — at $19-$299 it falls below the threshold where most cities require a comparative bid, which means the buyer can experiment without a 9-month RFP.
Appreciate the post-frame read on the ecosystem mapping — that's exactly the framing I was trying to land.
Solid play. The "category looks broken → build the scanner version" pattern is replicable — I shipped 3 BaaS security auditors this week on the same thesis (Supabase/PocketBase/Appwrite) where existing scanners charge $99-499/mo for what's basically metadata reads + a few HTTP probes.
Pushback on one bit: the FTC accessiBe order doesn't kill the overlay category, it kills deceptive marketing of it. The $50K agency audits are pricing in liability transfer (a human signed off and is on the hook) — that's effectively an insurance product, not a scanning one. Different SKU than what you're selling. I'd lean even harder into the "honest scanner" framing and not compete on the agency-quote axis at all.
Retention question: cities/govs buying once for compliance theater and never logging in again is the failure mode I'd watch hardest. What does month-2 look like for the $19 tier so far?
Both pushbacks are sharp.
The agency-quote axis: agreed, that's the wrong anchor. The $50K is liability transfer, and we shouldn't compete with insurance products on price. The cleaner frame is "the engineer's first-pass scan + fix tool" — the procurement officer still buys a manual audit on top for the human signature. The honest scanner stays a complement, not a substitute. I'll thread that through the marketing copy in the next pass.
Retention is the right question and the honest answer is I have no month-2 data — launched today. But the structural bets I'm making to dodge compliance-theater churn:
Curious how you're approaching retention on the BaaS auditors — same "audit becomes a CI step" structure, or different lever?
Thanks. The trap with regulation-driven demand though: the curve isn't "April 26, 2027 → spike." It's "RFPs going out now for FY27 budgets that need a tool referenced by Q3 2026."
Procurement runs 6-12 months ahead of deadlines because of budget cycles + RFP review windows + counsel sign-off. So the early-mover window for tooling is closing in a couple of months, not a year. Most founders chasing this market are mis-pricing the timeline by ~9 months.
The product direction is much stronger than the current branding frame.
You’re selling into procurement, compliance, legal exposure, public-sector trust, and engineering remediation workflows simultaneously. That’s not a “lab” category anymore — it starts behaving more like infrastructure once cities and agencies are involved.
The interesting part isn’t the scan itself. It’s the transition from “accessibility checker” → “continuous remediation infrastructure.”
That’s the layer that feels durable.
A tighter company-grade name would probably help more than expected once procurement conversations start compounding.
Exirra.com especially feels closer to the level of trust + infrastructure positioning this is moving toward than “PiposLabs” or “AccessiScan.”
Solid observation on the positioning frame — that's exactly the gap I've been wrestling with. Pipo Labs is the holding entity (a Wyoming LLC that owns 16 SaaS products). AccessiScan is one of them, marketed standalone. So "Pipo Labs" never appears in the procurement officer's view of the product — they buy AccessiScan, see AccessiScan in their VPAT, AccessiScan in their Stripe receipt.
You're right that once procurement conversations compound, the parent brand starts to matter (renewals, multi-product upsells, RFP language). I'm holding off on a parent rebrand until at least 3 products are profitable — too early to know which framing actually resonates with the buyer.
For the launch this week, AccessiScan is the standalone front door. The "lab" framing is intentionally low-stakes because the products are still proving themselves.
That makes sense.
If AccessiScan is the front door buyers actually see, then that’s the name carrying the trust load right now.
And that’s where I’d be careful.
“AccessiScan” explains the function, but it still reads like a checker.
That works for early launch clarity.
But the buyer you described is not just buying a scan.
They’re buying risk reduction, compliance confidence, and ongoing remediation support.
That’s a much heavier job than “scan.”
So the parent brand can wait.
But the product brand still has to answer this now:
does AccessiScan make procurement feel like they’re buying a serious accessibility infrastructure layer, or just another accessibility checker?
That gap matters before the 3-product parent brand question even starts.
Fair pushback — and you're right that the name leans transactional.
We named it AccessiScan deliberately, but for the opposite reason than you'd expect: procurement officers searching for a solution at 3am after the lawyer email arrives don't search "accessibility infrastructure layer" — they search "ada scanner" / "wcag scan." Tactical name = top of their funnel. We win the search, then the product reframes the conversation.
Sat with your comment for a few hours and realized the reframing was happening too late — buyers were hitting /pricing first and the $19-599/mo tiers were anchoring them in the "scanner tool" mental category before the product could do its work.
Just shipped /enterprise to address exactly that gap:
https://accessiscan.piposlab.com/enterprise
No $/mo numbers anywhere on the page. Same SKU, framed around the three jobs you called out (risk reduction, compliance confidence, ongoing remediation), with the procurement-grade contract surface on it (MSA/DPA/BAA, dedicated CSM, audit-trail database, 4-week timeline). Tactical name still wins the SERP; this page catches the buyer once they're in.
Curious if it lands the way you described, or if there's still a gap.
(h/t for the push — you sharpened something I'd been hand-waving.)
This lands much stronger.
The biggest improvement is that it no longer sells “scan.”
It sells procurement safety, legal confidence, and remediation continuity.
That is the right frame.
The page now makes the enterprise buyer feel like:
this survives legal review
this creates evidence
this keeps remediation moving after the scan
That is much closer to infrastructure than checker.
The only gap I still see is the name doing less work than the page.
AccessiScan still makes me expect a scanner.
The enterprise page then has to work hard to reframe it as compliance infrastructure.
That is fine for now if the tactical name wins search.
But if procurement becomes the real motion, I would watch whether buyers repeat:
“accessibility scanner”
or
“continuous compliance infrastructure”
That difference tells you whether the name is helping the category shift or forcing the page to compensate.
That's exactly the diagnostic I needed. We were treating the name question as binary (rebrand vs not) when it's really a measurement question.
Concrete plan: we'll log buyer language verbatim from the first 10 procurement calls / inbound emails into two buckets — "scanner" language (audit, scan, check) vs "infrastructure" language (continuous, compliance, evidence, remediation). If the infrastructure bucket is winning by call 8-10, the name is doing its job and the page is reinforcing the right shift. If it's not, we have a real signal that the page is compensating forever and the rebrand is on the table.
Will report back when we have data. This is the most useful framing I've gotten on positioning since launch — appreciate you sticking with it.
One practical thought since you’re already measuring buyer language from the first procurement calls.
This is exactly the kind of situation where a focused positioning audit would be useful, because the question is no longer just “does the page explain the product?”
The real question is whether the whole brand system is making buyers file AccessiScan as a scanner tool or as compliance/remediation infrastructure.
I can do a sharp written audit around that: name risk, enterprise page framing, buyer-language buckets, comparison risk, domain/category ceiling, and what signal would make a rebrand worth considering instead of premature.
Not a long consulting thing. Just a practical outside read you can use alongside the first 10 procurement calls and inbound emails.
I’m doing a few of these at $99 while refining the format.
For AccessiScan specifically, I’d focus on whether the current name can survive enterprise procurement, or whether the page will keep doing too much work to move buyers from “scanner” to “continuous compliance infrastructure.”
If useful, best place to discuss privately is here:
https://www.linkedin.com/in/aryan-y-0163b0278/
That’s the right way to measure it.
The important part is not whether buyers understand the page after reading it.
It’s what language they naturally repeat back.
If they keep saying “scanner,” the market is still filing you as a tool.
If they start saying “compliance evidence,” “remediation process,” or “continuous accessibility layer,” then the positioning is actually changing the category in their head.
That is the signal.
I’d also listen for who they compare you against.
If they compare you to scanner tools, AccessiScan is still anchoring the wrong category.
If they compare you to compliance workflows, legal review, or remediation systems, the enterprise frame is working.
That will tell you very quickly whether the name is helping or making the page do too much work.
Quick one for the thread, since I know the auto-fix angle is the part most readers will be skeptical about.
I just ran AccessiScan against news.ycombinator.com (the site we're literally on right now) — picked it because it's a famous, decade-old site that everyone here recognizes. Result: 75/100, 3 critical/serious WCAG violations:
— 2× Images without alt text (WCAG 1.1.1) — those tiny y18.svg upvote arrows and the HN logo
— 1× Form input without label (WCAG 1.3.1 + 4.1.2) — the search box in the header
— No <h1> heading on page (WCAG 2.4.6)
Each one comes with the source-code line that triggered it. The auto-fix pipeline reads the surrounding 5 files of context before drafting an aria-label / alt that fits the page's existing HTML conventions — so a Tailwind site gets a Tailwind utility, a Vue file gets a directive, etc.
Try it for free here, no signup: accessiscan.piposlab.com/free/wcag-scanner