Forem: asafamos

Why accessibility overlay widgets don't actually work (and the FTC just fined one $1M)

asafamos — Fri, 01 May 2026 11:41:05 +0000

You've seen the button. It floats in the corner of websites — a stylized stick figure or a wheelchair icon, sometimes pulsing slightly to attract attention. Click it and a panel pops up offering "accessibility profiles" — increase contrast, larger fonts, dyslexia mode, screen reader mode, content adjustments.

These are accessibility overlay widgets. accessiBe, UserWay, AudioEye, EqualWeb, and a handful of smaller vendors all sell variations of the same thing: a JavaScript file you add to your site that promises automatic ADA / WCAG compliance.

They don't work, and the regulators have noticed.

What an overlay actually does

The honest version is mechanical: an overlay loads in your visitor's browser, scans your DOM at runtime, and tries to patch missing accessibility attributes — adding aria-label here, adjusting role there, sometimes injecting a parallel UI for screen readers.

The implementation is impressive on demos. The reality on shipped sites is that:

Overlays can't fix what's structurally broken. A <div> with a click handler isn't a button just because you bolt role="button" onto it. The button still won't be in the keyboard tab order, won't have a focus state, won't announce its activation. AT users still can't use it.
Overlays add cognitive overhead for the very users they claim to help. The 2021 Deque User Study found that screen reader users spent 60-80% of their time fighting overlay-injected ARIA, not using it. Many disable overlays as a first step on any site they visit.
The fixes are bandaids. When the underlying HTML changes (a new button, a new form, an updated framework), the overlay's runtime patches go stale. The site looks compliant in a snapshot test against the overlay, then drifts.

What Princeton's 2023 study actually said

The widely-cited study on overlay effectiveness (Berkeley/Princeton 2023, Wagner et al) tested overlays against a panel of disabled users. The headline finding: overlays did not make websites more accessible by any measurable metric, and in some cases made navigation worse for screen reader and keyboard users.

The study's deeper finding: regulators evaluating WCAG conformance look at the served HTML — the HTML the server returns. Runtime JavaScript modifications don't count, because:

AT users frequently disable JavaScript or use AT that ignores client-side modifications
Some assistive technologies parse the page before scripts execute
The compliance standard (EN 301 549, referenced by EAA 2025) explicitly evaluates the server-rendered output

If your compliance argument requires JavaScript to execute correctly in every visitor's browser, you don't have a compliance argument.

The FTC just made this expensive

January 2025: the US Federal Trade Commission fined accessiBe $1 million and forced a permanent injunction against deceptive accessibility claims. The complaint cited:

accessiBe marketing the overlay as making sites "fully ADA compliant"
The company's own internal data showing screen reader users had material problems with sites running their widget
accessiBe instructing customers to use specific marketing language that the FTC found misleading

The settlement is here: ftc.gov press release. The signal is clear: regulators are not interested in widgets that rearrange runtime ARIA over broken HTML.

What actually works

The boring answer is: fix the source HTML and CSS, then prevent regressions with continuous integration.

The boring answer's expensive version is: hire an accessibility audit firm for $40K/year. They scan your site once a quarter, hand you a PDF, and recommend remediations. Most of what they find is automated — axe-core would have caught it, you just paid a human to read the output.

The boring answer's affordable version is: run the same automated scan as part of your CI pipeline on every pull request. Block merges on serious-severity regressions. Pair with one annual human audit (for the ~43% of WCAG criteria automated tools can't evaluate). Total cost: free CI tooling + ~$5-15K annual audit.

This is what large companies have been doing for years. It's just not flashy enough to be sold as a $5K/month subscription.

What to do if you're currently running an overlay

Don't panic-uninstall. The overlay isn't actively harming you (legally) until a regulator notices. Plan the migration.
Start with an audit of your actual HTML. Use npx axe-core/cli or axle or any other axe-core wrapper. See what the served HTML looks like.
Fix the serious findings. This is real work — usually 2-6 weeks of an engineer's time for a typical SaaS app.
Stand up CI. axle GitHub Action and similar tools run axe-core on every PR.
Schedule the human audit for after the CI baseline is clean.
Then uninstall the overlay. Update your accessibility statement. Notify any procurement/customer reviews that referenced the overlay.

The frame I find useful

Overlays are the runtime equivalent of putting "TLS" in your privacy policy without actually serving HTTPS. The label and the substance are different things. Compliance frameworks care about the substance.

Real WCAG compliance is unglamorous: semantic HTML, real labels, real focus states, real keyboard navigation. There's no shortcut. The good news is the work is bounded — most teams find that a one-time remediation effort plus continuous CI gets them to "passes regulator scrutiny" within a quarter.

I built axle because I wanted a CI-grade open-source alternative to the audit-firm tier. It's free for one repo. Full version of this post is on the canonical URL above. Drop questions in comments — happy to engage on the technical claims and the regulatory landscape.

I built an accessibility compliance SaaS in a day with Claude Code

asafamos — Sat, 18 Apr 2026 10:17:31 +0000

TL;DR — I'm not a primary coder. I spent ~12 hours on Saturday with Claude Code and shipped axle: an accessibility compliance CI that scans every PR for WCAG 2.1/2.2 AA violations and proposes AI-generated code fixes. It's live on GitHub Marketplace, npm, and a hosted web UI, and processed its first real $49 transaction the same day.

This is the honest play-by-play — the decisions, the dead ends, the Stripe-doesn't-serve-Israel detour, and what I'd tell someone trying to build a SaaS with AI as the primary contributor.

Why build this

Three things clicked at the same time:

The European Accessibility Act went into force in June 2025. Every company selling into the EU now needs WCAG 2.1 AA. Fines up to €1M per violation.
The FTC fined accessiBe $1 million in January 2025 for misleading AI claims about their overlay widget. That whole product category is legally radioactive.
Claude Sonnet 4.6 is good enough at targeted code fixes that the "AI auto-fix" pitch isn't marketing anymore — it actually works for ~60-75% of WCAG violations on realistic pages.

The wedge: real code fixes proposed as PR diffs, bundled with the legal artifacts a compliance officer actually needs (audit trail, accessibility statement, monitoring). Scanners are a commodity. The workflow isn't.

The stack I settled on

Every piece was chosen for "fastest path to first real revenue":

Next.js 16 on Vercel — App Router, server components. vercel deploy --prod in 30 seconds.
Playwright + axe-core 4.11 — the industry-standard scanner, wrapped in a headless Chromium.
@sparticuz/chromium — the serverless-compatible Chromium build. Needed once I realized Vercel functions don't ship a full browser.
Claude Sonnet 4.6 via the Anthropic SDK, with ephemeral prompt caching. Per-fix cost is ~$0.008.
Upstash Redis (via Vercel Marketplace, one click) for API-key storage and rate limiting.
Resend for transactional email.
Polar.sh as the merchant of record. This one deserves its own section.

The Stripe problem (and why Polar saved the day)

I'm Israeli. Stripe's dropdown for Business Location on a new account does not include Israel. I stared at it for ten minutes. I scrolled twice. No Israel.

Paddle was option B. I tried — and discovered my old Paddle account had been rejected years ago for an unrelated product (Swap-video, a face-swap tool that violated their acceptable use policy). Appeals exist, but take days.

Polar.sh (an MoR on top of Stripe Connect) was option C. Clean signup, no prior baggage, full KYC in one afternoon including identity verification. Bank account linked directly to my Israeli bank in USD. First real $49 charge processed end-to-end inside of six hours after signup.

If you're a non-US founder building SaaS in 2026: Polar.sh is the path.

How Claude Code actually feels as the primary contributor

I drove with a conversational loop: describe the next chunk, review the diff, ask for iteration. Claude wrote ~90% of the characters. What mattered from my side:

Knowing what I wanted at the product level (the pricing tiers, the legal positioning, the anti-overlay stance).
Catching when Claude over-engineered (it loves defensive programming; I rejected about a third of the try/catch blocks).
Forcing narrow scope (one feature at a time; no "while we're at it" refactors).
Recovering from dead ends fast.

The part Claude does not do for you: talking to customers, writing positioning copy that actually converts, choosing which channel to launch on.

Distribution, day one

GitHub Marketplace — asafamos/axle-action@v1.
npm — axle-cli and axle-netlify-plugin published.
Web UI — scan widget + Hebrew accessibility statement generator + embeddable compliance badge, all at axle-iota.vercel.app.
Scaffolds ready for Raycast, Chrome, Cloudflare Pages — publishing over the week.

Every output carries a "Powered by axle" trail: PR comments, generated statements, the badge itself (which is a backlink by definition). The product is the funnel.

What I learned

Legal pressure beats feature richness. The EAA/ADA/Israeli-law positioning converts better than any feature list.
KYC is the real bottleneck for non-US founders. Not coding. Not marketing. The paperwork.
Claude Code without product taste produces plausible-looking mush. With product taste, it produces shippable software in hours.
The "AI auto-fix" claim is defensible only with honest confidence scoring. Every fix axle generates ships with a confidence score and a manual-review flag.

What's next

More marketplace integrations — Cloudflare, Raycast, Chrome, VS Code.
Multi-language accessibility statements (French, German, Spanish) for full EAA coverage.
Custom domain, ProductHunt launch, and the inevitable "I scanned the top 100 SaaS landing pages" content marketing piece.

If you want to try axle (free tier: 1 repo, unlimited scans, bring your own Anthropic key):

Scan any URL: axle-iota.vercel.app
Install the Action: github.com/marketplace/actions/axle-accessibility-compliance-ci
CLI: npx axle-cli scan https://your-site.com

axle provides remediation assistance, not a compliance certificate. Automated tools catch ~57% of WCAG issues; manual human review is still recommended.