DEV Community: Romain

How Often Should You Run Accessibility Scans?

Romain — Mon, 08 Jun 2026 17:01:47 +0000

It is the second question every merchant asks after the first scan comes back: how often should I be doing this? Most tools answer with a pricing tier — weekly on the cheap plan, daily on the expensive one — as if accessibility decays on a schedule. It does not. A WCAG violation does not appear because a week went by. It appears because **something on the page changed: a deploy, a theme edit, a new product image, a third-party script update. The right scan cadence tracks your rate of change, not the calendar. This guide shows how to pick a frequency per site, why hourly is usually wasted, and why the cadence that actually catches regressions is the one tied to your deploys.**

Pick the row that matches how often the site changes. Then add a scan on every deploy — that is where regressions are actually born.

The question is per-site, not per-account

The first mistake is treating scan cadence as one global setting. A merchant typically runs more than one property: a marketing homepage that changes quarterly, a Shopify storefront that gets edited weekly, and maybe a help centre that almost never moves. Forcing all three onto the same schedule either over-scans the static ones (wasted runs, noisy history) or under-scans the active one (regressions sit undetected for days).

Cadence is a property of the site, not the account. The site that ships a new theme version every Tuesday needs a different rhythm than the one-page landing that has not changed since launch. Good monitoring lets you set the frequency independently on each tracked site, with your plan defining the fastest cadence available rather than dictating a single rate for everything.

Tie cadence to change, not to a calendar

A scan is a measurement. Measuring the same unchanged page every hour produces the same report every hour — that is not monitoring, it is a loop. The value of a scan comes from the delta: what is different since the last clean run. So the useful cadence is whatever frequency keeps the delta small enough to act on without drowning you in identical reports.

Concretely, accessibility regressions enter a site through a handful of events:

Deploys. A developer ships a new component, a refactor changes the DOM, a dependency bump alters rendered markup. This is the single largest source of new violations.
Theme and template edits. On Shopify and similar platforms, a non-technical edit in the theme editor can break heading order, remove a label, or drop contrast below the threshold.
Content and catalogue changes. A new product with a missing alt text, a banner image with text baked in, a promo block pasted from a supplier.
Third-party scripts. A chat widget update, an A/B testing tool, an embedded video player — code you did not write, mutating your page at runtime.

Notice what is not on that list: the passage of time. Nothing about Tuesday becoming Wednesday introduces a contrast failure. This is why mapping cadence to your change rate — rather than picking the biggest number your plan allows — is the whole game.

Recommended cadences by site type

Use this as a starting point, then adjust based on what your scan history shows:

Static brochure or landing page — changes a few times a year. Monthly is plenty. The monthly run mostly proves nothing regressed, which is exactly the dated evidence you want for compliance anyway.
Active e-commerce store — weekly content and catalogue edits, occasional theme tweaks. Weekly keeps the delta small enough that any new violation is traceable to that week's changes.
High-velocity site — frequent deploys, seasonal promos, multiple editors. Daily. At this pace a week is too long; a daily baseline narrows any regression to a single day of changes.
Anything with continuous deployment — see the next section. The calendar cadence becomes a backstop; the deploy trigger does the real work.

Why hourly is usually overkill

Hourly scanning sounds thorough, and there are narrow cases for it — a high-traffic site during a launch window, or a page assembled from rapidly-changing third-party feeds. But for the overwhelming majority of e-commerce sites, hourly scanning measures the same unchanged page 24 times a day. WCAG conformance is not a metric that drifts hour to hour like CPU load; it steps when the markup steps. An hourly cadence on a site that deploys twice a week generates 333 identical reports for every one that actually shows a change.

That noise has a cost. A scan history full of identical runs makes it harder to spot the run that matters. The signal — the report where something broke — is buried under hundreds of green duplicates. We deliberately do not push hourly as the default recommendation, even though the top plan supports it, because for a normal store it trades a real benefit (a clean, readable history) for a theoretical one (catching a regression an hour sooner that a deploy-triggered scan would have caught instantly anyway).

Scan-on-deploy: the cadence that actually matters

If a scan should run when the site changes, and a deploy is the biggest source of change, then the highest-value trigger is obvious: scan on every deploy. Instead of hoping your daily timer happens to fire after a risky deploy, you wire the scan into the moment the change ships.

For teams with a CI pipeline, this is a single step: after the deploy job succeeds, hit the scan endpoint (or run an axe-core pass in CI directly) against the URLs that changed. The scan becomes part of the release, the same way a smoke test is. A regression is caught in the same pipeline run that introduced it — before a customer, a regulator, or a plaintiff firm ever sees it.

For merchants without a CI pipeline — most Shopify stores — the equivalent is a tight calendar cadence (daily or weekly) plus a manual scan after any theme publish or large catalogue update. The discipline is the same: scan when the site changes, not just when the clock ticks.

Scan-on-deploy also fixes the noise problem from the previous section. You no longer need an aggressive timer to feel safe, because the timer was never what caught regressions — the change trigger was. A weekly backstop scan plus a scan on every deploy beats an hourly timer on both coverage and signal.

What the delta tells you

Once cadence tracks change, your scan history becomes a changelog of your site's accessibility. Each run is a diff against the last: violations resolved, violations introduced, score moved. That history is more useful than any single report, because it answers the question that matters in a remediation programme — are we getting better or worse, and which change caused which?

This is also where the audit workflow and continuous monitoring meet. A one-shot audit gives you a baseline. Cadenced scanning turns that baseline into a trend line. When a violation reappears, the timestamp tells you which deploy or edit reintroduced it, which is half the work of fixing it.

Mapping cadence to your plan

Here is how the per-site model works in practice. Your plan sets the fastest cadence you can choose; you then set each site at or below that ceiling based on its change rate:

Starter — up to 5 sites, weekly ceiling. Set the active store to weekly, the brochure site to monthly. Good for a single merchant with a couple of properties.
Pro — up to 25 sites, daily ceiling. Set high-velocity sites to daily, steady stores to weekly, static pages to monthly. This is the typical agency or multi-store setup.
Business — many sites, hourly ceiling available. Use hourly only on the rare site that genuinely needs it; keep the rest on the cadence their change rate justifies.

The point of independent per-site cadence is that you are not paying the "scan everything daily" tax on sites that change twice a year. You spend frequency where change happens. See the plans and ceilings for the exact limits.

The compliance angle: dated evidence

There is a second reason cadence matters, beyond catching regressions: it produces a paper trail. The ADA and the European Accessibility Act both reward contemporaneous evidence — proof that you were actively monitoring and remediating, dated, before any complaint. A site scanned monthly with a clean history of dated reports is in a materially stronger position than one with a single scan from eighteen months ago.

Even a static site that "never changes" benefits from a monthly scan for this reason alone. The runs are nearly identical, but each one is a dated record that conformance held. That record is the artifact a corporate buyer asks for in a VPAT request, and the one plaintiff counsel cannot easily dispute.

How to set your cadence

List your sites and their change rate. Be honest: how often does each actually change? Most accounts have one active site and several near-static ones.
Match each site to the table above. Static to monthly, active to weekly, high-velocity to daily. Start conservative; you can always tighten it.
Add a deploy trigger where you can. If you have CI, wire a scan into the release. If you are on Shopify, scan manually after every theme publish.
Watch the first month of history. If every run is identical, you can loosen the cadence. If you see regressions you missed, tighten it — or improve your deploy trigger.
Keep the dated reports. They are your evidence trail, independent of whether they ever catch a regression.

If you have not set a baseline yet, start there: run a free WCAG 2.2 scan on any URL — full violation list, severity breakdown, no signup. Then walk the step-by-step audit on the findings, set a per-site cadence that matches how often the page changes, and let the deploy trigger do the heavy lifting. Cadence is not about scanning more. It is about scanning when it counts.

Originally published on access-proof.com.

Why Our WCAG Scanner Is Free (And What That Costs Us)

Romain — Thu, 28 May 2026 08:39:28 +0000

Run a search for "free WCAG scanner" and the pattern repeats. You land on a page that promises a free audit, then asks for your email, your role, your company size, and sometimes your phone number. Then it shows you violations. We took the other side of that bet. /free-wcag-scan runs a full axe-core pass on any URL — about 120 rules covering WCAG 2.2 A and AA — and returns the report in roughly 90 seconds. No account, no card, no email gate. Here is the math behind that decision and what it actually costs us per scan.

The gated funnel sells "the report" as a lead magnet. The open funnel sells the platform — and lets the report itself do the qualifying.

The math behind a single scan

A real WCAG scan is not a clever algorithm. It is a browser. We boot a containerised Chromium, load the URL, wait for paint and idle, inject axe-core (the same engine Lighthouse uses), run the 120-rule pass, capture screenshots of every violation, and emit a structured JSON report. The pipeline runs on a small Fly.io worker, around 1.5 GB of RAM, that idles when nobody is scanning.

The unit economics break down like this:

Chromium time — about 8 to 14 seconds of compute per URL, depending on page weight. At Fly.io's shared-cpu-1x:2048MB rate, that works out to roughly $0.0008 to $0.0014 in raw compute.
Bandwidth — a typical e-commerce homepage is 2 to 5 MB. Outbound is free on Fly within our allowance; inbound from origin is essentially zero.
Storage — screenshots and JSON reports for a free scan are kept 7 days and then purged. Average storage cost per scan: under $0.0001.
The fully-loaded number — counting amortised infra (DB, Redis, the worker reservation that keeps cold-start under 2 seconds), we land at roughly $0.03 per free scan. Three cents.

If 1,000 visitors run a scan in a month, that is $30 of marginal compute. Less than a single Google Ads click in our category.

What you actually get

The free scan is not a teaser. It returns:

A WCAG 2.2 A + AA compliance score — the same headline number we display inside the paid product.
The full list of violations — sorted by severity (Critical, Serious, Moderate, Minor), with the failing selector, the rule ID, the WCAG criterion, and a screenshot of the element.
Plain-English explanations — for each rule, what it means and the typical fix. No "consult our enterprise team to learn more."
Issue prioritisation — the five issues most likely to appear in a demand letter, called out at the top.

What it does not include — and this is the honest answer:

No PDF report. Generating a PDF reliably costs us about ten times the scan, in Chromium time, because we render the report with print layout. PDF is a paid-plan feature.
No history. The free scan is one-shot. You get a URL to share for 7 days, then we purge it. Tracked sites with re-scan history are a paid-plan feature.
No multi-page crawl. The free scan runs against the URL you paste. The paid plans crawl the sitemap and audit every page.
No screen reader narration check. Automated tools, ours included, do not catch what a screen reader user actually hears. About 30% of real accessibility issues need human review — see the pillar guide for the full breakdown.

The bet

Most accessibility SaaS treats the report as a lead magnet. Logical, on paper: the violation list is what the buyer wants, and the email is what the sales team wants. Trade one for the other.

We think that funnel is broken for our product specifically, for three reasons.

One. A merchant who hands over their email under a "free scan" pretext converts on different intent than a merchant who has already read their own violation list. The first wants the scan. The second wants the fix. The economics of a SaaS that sells continuous monitoring favour the second cohort heavily.

Two. Our category is saturated with overlay widgets that promise compliance and deliver a documented liability. Trust is the bottleneck. If we ask for an email before showing a single rule failure, we are using the same playbook as the overlays. We are not the overlays.

Three. The cost of a scan is below the cost of a single ad click. The math only works against us if we measure success by leads captured. Measured by qualified pipeline — merchants who arrive having seen their own report and ready to talk about the fix — it works the other way.

What happens after the scan

Nothing happens automatically. We do not capture an email, so there is no drip sequence. We do not have your phone number, so nobody calls. The shareable URL expires in 7 days. The Chromium worker forgets you existed.

If you want the rest — PDF, history, multi-page crawl, tracked sites — you self-select into the paid plans. Starter at $29/month covers 5 sites with weekly scans. Pro at $99 covers 25 sites daily. The first scan stays free because it was always supposed to be free.

The regulatory backdrop

The European Accessibility Act came into force on 28 June 2025. EU member states are now actively enforcing it for consumer-facing digital services, with the bulk of e-commerce sites in scope. The US side is older — Title III of the ADA has been interpreted to cover websites since at least 2017 — and the cadence of ADA demand letters targeting websites grew roughly 14% year-over-year through 2024 and accelerated again in Q1 2026.

Two regimes, one reality: if your e-commerce isn't audited, you're working on borrowed time. The deadline isn't "later this year." It's whichever comes first — the regulator inspection, the plaintiff firm crawler, or the corporate buyer asking for your VPAT.

A scan that costs us three cents and gives a merchant a baseline they can act on is, in that context, the cheapest pre-emptive action available.

How to use it

Run it on your homepage first. Most demand letters cite the homepage and the checkout flow. The homepage is the easiest to fix and the highest-visibility win.
Run it on a competitor's homepage too. Useful to know whether your category is well-audited or whether you are entering a space where compliance is broadly poor.
Skim the Critical and Serious findings. Those are what plaintiff firms screenshot. If you have fewer than five, you are ahead of the median.
Walk the 7-step manual audit workflow on the items the scan flags. Automated catches the patterns. The 7-step walk catches the rest.
Decide whether you want this continuously. A one-shot scan is a baseline. Conformance is a rhythm. The paid plans exist for the rhythm.

That is the whole pitch. /free-wcag-scan. No email, no card, no overlay. Three cents on our side, a real baseline on yours.

Originally published on access-proof.com.

Website Accessibility Audit: The Complete Guide (WCAG 2.2)

Romain — Wed, 27 May 2026 09:39:22 +0000

A **website accessibility audit is a structured review of a website against the Web Content Accessibility Guidelines (WCAG) — the technical standard cited by the ADA (United States), the EAA (European Union, June 2025), and Section 508 (US federal). Done properly, an audit produces two things you can actually use: a prioritized list of issues to fix, and dated evidence that you are conforming on an ongoing basis. This guide explains what an audit covers, who needs one, what tools and methods exist, and what the deliverable should look like.**

What an audit actually checks

WCAG 2.2 has 86 success criteria across four principles: Perceivable, Operable, Understandable, Robust. An audit checks each criterion that applies to your pages, at the conformance level you target (A, AA, or AAA). Most legal contexts target WCAG 2.2 Level AA — that is what the ADA case law and EAA technical specifications converge on.

For each criterion, the audit answers three questions:

Does this criterion apply? (e.g., 1.2.2 Captions only applies if you have pre-recorded video)
Are you passing? If yes, document the evidence (which page, which element, which check).
If failing, what is the severity? Critical / Serious / Moderate / Minor — driven by user impact and legal exposure.

Who needs an audit

Three groups commonly trigger an audit:

Sites that received an ADA demand letter or a settlement notice. The audit is the first artefact your counsel will ask for. See our 72-hour ADA demand-letter playbook.
EU-facing businesses preparing for the European Accessibility Act (enforcement started June 28, 2025). Even non-EU companies trading into the EU above defined thresholds are in scope. See EAA 2025 requirements.
SaaS and ecommerce teams responding to procurement. Enterprise buyers, government, education, and healthcare procurement increasingly attach a VPAT request (or its EU equivalent, a Conformance Report) to their RFP. See how to produce a VPAT.

Automated vs manual vs user testing

Industry consensus is that automated tools catch 30 to 50 percent of WCAG failures. The exact figure depends on the site — heavy on forms and dynamic widgets, automated coverage drops; mostly static text content, automated coverage peaks. The remaining 50 to 70 percent requires manual checks: keyboard-only navigation, screen reader walk-throughs, 400% zoom layout, focus management on modals and drawers, cognitive load on error states and form recovery. The last 5 to 10 percent — checks like "is the workflow understandable to a screen reader user under time pressure" — only emerges from user testing with people who actually rely on assistive technology.

A reasonable audit balances all three layers. Automated runs continuously (CI on every deploy, plus a scheduled scan), manual is done quarterly or per major release, user testing is done annually or for new flagship features. The step-by-step workflow we use covers the manual layer in detail.

Tools we actually use

Automated — axe-core via AccessProof (continuous), Lighthouse, WAVE for spot checks. axe-core has the lowest false-positive rate of the open-source engines. See axe-core vs Lighthouse.
Keyboard — Tab, Shift+Tab, Enter, Space, Esc, arrow keys. Every interactive element must be reachable and operable. No keyboard traps. Focus indicators visible.
Screen reader — NVDA (Windows, free), VoiceOver (macOS / iOS, built-in), JAWS (Windows, dominant in enterprise) on at least Chrome and Safari. Basics here.
Color contrast — automated for normal text and UI, manual review of brand colors and adjacent surfaces. Free contrast checker.
Zoom & reflow — 400% zoom in a 1280-wide viewport. Content must reflow to one column, no horizontal scrolling except for data tables.

What the deliverable should look like

A defensible audit report contains:

Date and scope — which URLs were audited, which standard and conformance level was targeted, when (timestamps matter — they bound the plaintiff's claims).
Methodology — automated tools used (with version), manual checks performed, assistive technology versions tested.
Per-criterion finding — pass / fail / not applicable, with evidence for each failure (selector, screenshot, expected behavior).
Severity-ranked remediation list — Critical and Serious first, with effort estimate and owner.
Re-test plan — when the next audit happens, what the cadence is. Continuous improvement is what most plaintiff firms settle around.

How often to audit

Three rhythms run in parallel:

Continuous (automated) — every deploy. Catches regressions before they ship. AccessProof Starter covers 5 sites weekly; Pro covers 25 sites daily; Business covers unlimited hourly.
Quarterly (manual + automated) — a human walks the critical flows on top of the continuous scans.
Annually (full audit + user testing) — comprehensive, all pages, all flows, with assistive technology users where budget allows.

Cost and effort

An automated baseline scan is essentially free (we run them under a minute on our infrastructure for $0 on the Free plan). A manual quarterly review by an internal team typically takes 8 to 24 hours per site depending on complexity. A full external audit by a specialist agency runs $5k to $25k per site, more for SPAs and dashboards. The math almost always favours running automated continuously and reserving manual / specialist time for the criteria automation cannot cover.

Common mistakes

Auditing once and shipping it. An audit dated more than 90 days ago is stale evidence — the site has likely changed underneath it. Continuous beats one-shot.
Ignoring focus management. Modals, drawers, and dynamic content are where most lawsuits originate. Automated tools rarely catch focus-trap failures.
Color contrast on hover and disabled states. The default state passes, the interactive states fail. Audit every state, not just resting.
Forms without programmatically associated labels. Placeholder text is not a label. We see this on roughly 40% of new audits.
Relying on an overlay widget. Why overlays are a documented liability.

Where to start

If you have not run any kind of accessibility check on your site, start with the smallest commitment that produces dated evidence: run a free WCAG 2.2 scan on any URL. You get a compliance score, the four-tier severity breakdown, and the top five issues — no signup, no overlay, no marketing loop. Use that as the baseline against which to plan the rest of the audit work. For continuous monitoring across multiple sites, the Starter plan ($29/mo) covers 5 sites with weekly scans and PDF reports; Pro and Business escalate to daily and hourly cadence.

Once you have a baseline, walk the 7-step manual workflow on your three most critical flows: signup, checkout (or primary conversion), and the dashboard or member area. Those three flows are what plaintiff firms screenshot in demand letters. Fix the Critical and Serious findings first. Document each fix with a date, a commit, and the next re-scan result that confirms it. That documented sequence — issue identified, fix shipped, re-scan green — is the contemporaneous evidence the ADA and EAA processes expect.

Originally published on access-proof.com.

We Leaked 1,368 Customers into Our LIVE Stripe Account via E2E Tests

Romain — Tue, 26 May 2026 14:08:49 +0000

Six weeks ago we wired up signup-to-paid-plan E2E tests against our staging stack. Last week we found 1,368 fake customers in our production Stripe account. No charges. No invoices. No alert ever fired. Here is what went wrong, the boring fix, and a checklist to see whether the same pattern is silently filling your own Stripe.

The pattern fires silently. Stripe charges nothing for Customer objects, so the usual monitoring catches none of it.

The setup that looked fine

Our signup flow does what every SaaS signup flow does. POST email and password → create a row in users → call stripe.Customer.create with the email → store the returned cus_xxx on the user row → send a welcome email. Nothing exotic.

Our E2E suite, run on every commit to master, signs up a fresh user, walks the onboarding, hits the dashboard, signs out. Around 30 signups per CI run. Test emails follow a pattern: {slug}+e2e@access-proof.com.

Two assumptions, both wrong:

We assumed the CI environment was configured with the Stripe TEST secret key. It was not. Someone had set it to LIVE during a debugging session a couple of months back. The CI variable was never reverted.
We assumed Stripe would somehow flag the obviously-fake emails. It does not. Creating a Customer object is rate-limited but otherwise free. There is no fraud signal, no review queue, no email-bounce side effect, no soft alert.

Six weeks of pushes × ~30 signups × CI = ~1,400 fake customers. Almost all of them disposable email addresses ending in +e2e@access-proof.com, but a handful with other test patterns we use in scripts.

How we found it

By accident, looking at the "Customers" page of the Stripe dashboard during a debugging session for something else. The total count surprised us — we have maybe 80 real signups so far. Sorting by recency showed a torrent of +e2e@ addresses.

What didn't catch it: no monitoring, no Stripe webhook (we listen for invoices and subscriptions, not raw Customer creates), no email alert (Stripe doesn't send any), no quota issue (we are nowhere near Stripe's account-level limits).

The lesson is uncomfortable. Compliance debt — and this is a flavour of GDPR-relevant data hygiene — does not always announce itself. It accumulates quietly in places nobody has a reason to look.

The boring fix

Two changes. First, the email-pattern skip at the boundary:

# app/services/billing.py

TEST_EMAIL_PATTERNS = (
    re.compile(r".+\+e2e@access-proof\.com$"),
    re.compile(r".+\+test@.+$"),
    re.compile(r".+@mailosaur\.io$"),
)

def is_test_email(email: str) -> bool:
    return any(p.match(email) for p in TEST_EMAIL_PATTERNS)

async def create_stripe_customer_if_real(user: User) -> str | None:
    if is_test_email(user.email):
        logger.info("stripe.customer.skip", email=user.email)
        return None
    customer = await stripe.Customer.create_async(email=user.email)
    return customer.id

Second, the boot-time guard so the same drift cannot happen again:

# app/main.py

if settings.STRIPE_SECRET_KEY.startswith("sk_live_") and os.getenv("CI") == "true":
    raise RuntimeError(
        "Refusing to boot: LIVE Stripe key detected in CI environment. "
        "Set STRIPE_SECRET_KEY to a TEST key (sk_test_...) for CI."
    )

This is the fix that pays back. The first change makes the bug impossible at the application level. The second makes the misconfiguration loud at startup, so it surfaces during the next pipeline run, not six weeks later.

The purge

Cleaning up the 1,368 ghosts was a one-shot script:

# scripts/purge_stripe_test_customers.py

import stripe, time

stripe.api_key = os.environ["STRIPE_LIVE_KEY"]
DELETED = []

for c in stripe.Customer.list(limit=100).auto_paging_iter():
    if is_test_email(c.email or ""):
        stripe.Customer.delete(c.id)
        DELETED.append({"id": c.id, "email": c.email})
        time.sleep(0.1)  # respect rate limit

print(f"Deleted {len(DELETED)} test customers")
# write CSV audit trail
with open(f"deleted-{date.today()}.csv", "w") as f:
    csv.DictWriter(f, ["id", "email"]).writerows(DELETED)

About 12 minutes of script time. A CSV with the 1,368 IDs and emails went into our audit folder. Stripe's rate limit on the Customer endpoint is about 100 requests per second; our 10-per-second pace is conservative and avoids any 429s.

What else might be leaking silently

Once you start looking, the pattern repeats. Things that get created in tests but never trigger a charge, an invoice, or an alert:

Mailgun / SendGrid contacts — every welcome email adds a contact unless you skip on test addresses.
Mixpanel / Segment / Amplitude identify calls — every test signup becomes a real user in your analytics, polluting funnel data.
Algolia / Meilisearch indexes — if you index users for admin search, your index fills with fake rows.
CRMs (HubSpot, Pipedrive) — every signup creates a contact. Sales calls a real-looking lead address that bounces.
S3 / R2 buckets — if test signups create folders or default assets, you grow object storage forever.

For each one, the fix is the same: pick a stable test-email pattern, skip the call at the boundary, add a boot-time guard against mode drift.

The audit trail matters more than the deletion

If you discover a leak like this and there is any chance the data flowed to a third party, keep a dated record. GDPR Article 5 (data minimisation) and Article 32 (security) are about being able to show what you did. A CSV of the 1,368 IDs you purged, dated and committed somewhere durable, is better than a cleaner slate with no record.

We also added the leak to our internal PITFALLS.md — the running register of mistakes we never want to repeat. If you do not keep one already, the entry takes one line: date, what happened, root cause, the boring fix that prevents the recurrence.

One last check

Go open your Stripe dashboard. Sort customers by recency. Skim the last 100. If you see emails with +test, +e2e, @example.com, @mailosaur, or your CI-tagged patterns — you are doing the same thing we were. Apply the four-step fix above. The whole job is under an hour.

For everything else that runs silently in the background of a SaaS — accessibility regressions, RGPD lapses, broken email deliverability — the free WCAG scan we run is the same flavour of low-effort, dated audit. It will not catch a Stripe leak. But it will catch the accessibility issues your tests are not even trying to find.

Originally published on access-proof.com.

Overlay Widgets vs Real WCAG Scanners: A 2026 Buyer’s Guide

Romain — Tue, 26 May 2026 14:08:18 +0000

Two categories of tool dominate the accessibility software market. Overlay widgets — accessiBe, UserWay, AudioEye — inject WAI-ARIA attributes at runtime and promise instant ADA compliance for a flat monthly fee, typically **$490 to $1,490 per site per year. Real scanners — Pope Tech, Silktide, Monsido, axe-core, AccessProof — audit your actual rendered DOM and report issues you then have to fix. Real scanners cost ~10x less and ship the work back to your codebase, where it belongs. This guide is the version of the comparison we wish merchants had before signing one.**

The architectures differ at the foundation. The pitch differs at the surface.

What overlays actually do

An overlay is a JavaScript snippet you paste into your site. It loads on every page, scans the DOM at runtime, and adds ARIA attributes (role, aria-label, tabindex, etc.) to elements it detects as missing them. Most overlays also expose a sidebar widget letting the user toggle visual settings — high-contrast, larger fonts, dyslexia-friendly typeface.

That part — the visual toolbar — is benign. It mimics what the operating system already provides and what every modern browser supports natively. The disabled-user research community has been clear for years that the toolbar duplicates capabilities most users either already have or do not want.

The other part — automatic ARIA injection — is where the harm is. Overlays cannot infer semantic intent from broken HTML. A `styled as a button getsrole="button"bolted on, but no keyboard handler, no focus state, no properaria-pressed` for toggles. A screen reader receives a button that is not really a button. A keyboard user receives a focus target that does nothing.

What real scanners do

A real scanner runs an audit engine — typically axe-core — against the actual rendered HTML. It enumerates violations by WCAG success criterion, severity (critical / serious / moderate / minor), and DOM node. The output is a list. You read it, you fix the source code, you re-scan.

Automated scanners catch roughly 30 to 50 percent of real WCAG issues — color contrast, missing alt, broken heading hierarchy, label-input pairs, ARIA misuse, target size. The remaining issues — keyboard traps, screen-reader logic, dynamic content, focus management — require manual review by someone with assistive-technology experience. Honest scanner vendors say this upfront. Overlays vendors claim 95 percent or more, sometimes "full compliance," through automation alone.

The six tools we benchmarked

The market splits cleanly into the two categories.

Overlay vendors

VendorMechanismPricing (small site)Notable

accessiBeJS overlay + AI-driven ARIA injection~$490–$1,490/yrLargest vendor. Named in the Federal Trade Commission settlement (2024) over deceptive accessibility claims.

UserWayJS overlay + user toolbar~$490–$890/yrOwned by Audioeye since 2023. Same overlay-injection approach.

AudioEyeJS overlay + claimed human audit overlay~$590–$1,490/yrPositions as "automation + human review." The human review is shallow on the smaller tiers.

Real scanners

VendorMechanismPricing (small site)Notable

Pope TechWAVE engine (real DOM audit)~$59–$199/yr (small)Built by WebAIM partner. Honest scope: catches what automated rules catch.

SilktideProprietary scanner + page-level audits~$199–$990/yrStronger CMS-style reporting. Designed for content teams.

MonsidoSite-wide scan + accessibility + SEO + QA~$3,000+/yrEnterprise-skewed. Bundle of compliance scanners.

AccessProof (us)axe-core engine + monitoring + reports$0–$49/moFree no-signup scan, monitoring, dated reports for defense file.

What the courts have said

The legal picture has shifted decisively against overlays in the United States.

FTC enforcement (January 2024) — the Federal Trade Commission concluded that accessiBe's claims of automatic ADA and WCAG compliance were deceptive. The company settled for $1 million and was prohibited from making similar claims.
Active litigation — overlay-installed sites continue to be sued under ADA Title III. Courts have consistently rejected the argument that an overlay is a defense; the underlying HTML is what determines accessibility.
The disabled community position — over 800 accessibility specialists have signed the Overlay Fact Sheet recommending against overlay use. Many screen-reader users actively block overlays.

An overlay does not protect you from an ADA lawsuit. If anything, it can complicate the defense: a plaintiff can argue the merchant knew about accessibility but chose a tool that does not actually fix the underlying issues.

Decision framework — how to pick

Three questions, answered honestly:

Are you optimising for the appearance of compliance, or for the experience of disabled users? The first is short-term — until the next demand letter. The second is the only thing that holds up in front of a screen-reader user, a regulator, or a judge.
Can your team or vendor fix the source HTML? If yes, you want a scanner. If absolutely not (legacy CMS you cannot touch, third-party platform with no edit access), the conversation is about platform migration, not overlay rescue.
Do you need defense evidence? Dated reports of audits performed and remediation history are a real defense in an ADA case. A scanner produces them; an overlay does not.

If you would rather see what your site actually scores before deciding, our free WCAG scan runs the axe-core engine on any public URL, no signup, in under a minute. The same engine powers our paid plans. If the free scan returns 8 critical violations, an overlay does not make them go away — it papers over them.

Closing

The market has been mature enough for long enough that the comparison should not feel controversial. Real scanners cost less, do less marketing, and produce work that survives legal scrutiny. Overlays cost more, market more, and produce work that has now drawn FTC enforcement against the largest vendor. We bet on the scanner path. We think you should too.

Originally published on access-proof.com.

How an Accessibility SaaS Broke Its Own Landing (and How We Fixed It)

Romain — Tue, 26 May 2026 14:07:47 +0000

We sell accessibility audits. Last week, we shipped a marketing landing for our scanner. It used scroll-triggered reveals. Under prefers-reduced-motion the reveals never resolved — the content stayed invisible. Our own landing failed the test we sell. Here is the one-line CSS fix, the Playwright assertion that locks it in CI, and what to look at in your own codebase.

Same visual intent, two implementations. Only the right one is safe.

The bug

Modern marketing pages use reveal-on-scroll animations. The element starts invisible (or off-position), then animates into view when it enters the viewport. The canonical CSS looks like this:

.reveal {
  opacity: 0;
  transform: translateY(20px);
  transition: opacity 600ms ease, transform 600ms ease;
}
.reveal.is-visible {
  opacity: 1;
  transform: translateY(0);
}

An IntersectionObserver toggles .is-visible as the element scrolls in. Looks great.

Then someone with vestibular disorder, migraine sensitivity, or ADHD opens your site. Their OS-level setting is Reduce motion. Their browser exposes this via prefers-reduced-motion: reduce. Most animation libraries respect it correctly: when reduced motion is requested, transitions are disabled.

That is precisely the problem. With transitions disabled, the element never moves from its start state. opacity: 0 stays at opacity: 0. The reveal never resolves. Your visitor sees a blank page.

Why opacity-driven reveals are an accessibility bug, not a feature

It is tempting to think the browser is being "too literal." It is not. Reduced motion is a contract: do not animate. The browser honours it by not running the keyframe. The bug is in your CSS: you encoded the visible state as the end of an animation that you have just told the browser to skip.

WCAG 2.3.3 (Animation from Interactions, AAA) and the broader principle in WCAG 2.1 §2.3 are about avoiding harm. But here we are not even debating triggers — we are removing the visible content entirely. The reveal becomes a display: none for anyone with reduced motion enabled.

The transform-only fix

Stop animating opacity. Animate only transform:

.reveal {
  transform: translateY(20px);
  transition: transform 600ms ease;
}
.reveal.is-visible {
  transform: translateY(0);
}

Now opacity stays at its default of 1. Under reduced motion, the browser skips the transform, the element appears at its final position immediately, content visible from first paint. With motion enabled, the translate plays as before. Same visual intent, no regression.

For the genuine case where you need opacity (a fade-in modal, a real cross-fade), wrap the rule:

@media (prefers-reduced-motion: reduce) {
  .reveal { opacity: 1; transition: none; }
}

This says, plainly: under reduced motion, no transition, content visible. Two lines, no library needed.

Locking the regression out with Playwright

Code fixes are easy to lose during a refactor. A test makes the rule permanent. In Playwright:

import { test, expect } from '@playwright/test'

test('reveals remain visible under prefers-reduced-motion', async ({ page }) => {
  await page.emulateMedia({ reducedMotion: 'reduce' })
  await page.goto('/')
  const reveals = page.locator('.reveal')
  const count = await reveals.count()
  for (let i = 0; i  getComputedStyle(el).opacity)
    expect(Number(opacity)).toBeGreaterThan(0.99)
  }
})

Wire it into your CI as a blocking job. Now no future commit can re-introduce the bug without the pipeline turning red.

Other places this pattern hides

Hero text fade-in — same opacity issue. Replace with translateY or remove entirely.
Stagger reveals on cards — each card with opacity: 0 until a delay-based trigger fires. Same fix.
Skeleton loaders that fade out — if the real content fades in via opacity, under PMRM you get both layers stuck. Use display swap or set opacity:1 under PMRM.
Off-canvas drawers with opacity transitions on inner content — drawer opens, content invisible.
Toast notifications that animate in with opacity — the toast appears empty.

How to find every offender in your codebase

A blunt grep is usually enough:

grep -rE "opacity:\s*0" --include="*.css" --include="*.scss" --include="*.tsx" .

Anything that returns deserves a look. The fix is repetitive but mechanical.

If you ship motion at all, audit your codebase once and add the Playwright guard once. After that the rule self-enforces. Total cost: an hour. Cost of skipping it: any user with reduced motion enabled cannot see your landing page.

Run a free scan of your own landing

If you have not audited your own marketing site lately, our free WCAG scanner runs axe-core on any public URL, no signup, returns a triaged report in under a minute. It will not catch this specific bug (reduced-motion testing is not part of WCAG conformance criteria — axe-core does not emulate user preferences), but it will catch most other things. For the reduced-motion case specifically, run the Playwright test above. It is the cheapest insurance you can buy against an entire class of accessibility regressions.

Originally published on access-proof.com.

Web Accessibility Statement: Template + Examples

Romain — Fri, 22 May 2026 07:27:21 +0000

An accessibility statement is a public page declaring your conformance target, known limitations, and how to report problems. It is not legally required everywhere, but it is one of the cheapest, highest-leverage things you can publish — and it matters in an ADA dispute.

Why publish one

It signals good faith — a documented commitment with a feedback channel is part of the defensible posture plaintiffs settle around.
It is required by some laws (EU public-sector bodies under the Web Accessibility Directive must publish one; the EAA expects accessibility information).
It gives real users a way to report barriers and get help.

What to include

Commitment — a sentence stating you are committed to accessibility.
Conformance target — e.g. we aim to conform to WCAG 2.2 Level AA.
Current status — fully conformant, partially conformant, or in progress (be honest).
Known limitations — areas you know fall short, with a plan to fix them.
Feedback mechanism — an email or form, with a response-time commitment (e.g. 5 business days).
Date — when the statement was last reviewed.

Copy-paste template

Adapt the following to your organisation:

Accessibility Statement for [Company]

[Company] is committed to ensuring digital accessibility for people
with disabilities. We aim to conform to WCAG 2.2 Level AA.

Status: Partially conformant — most of the site meets WCAG 2.2 AA;
some areas are being remediated.

Known limitations: [list, with target dates].

Feedback: If you encounter a barrier, email accessibility@[company].com.
We aim to respond within 5 business days.

This statement was last reviewed on [date].

Common mistakes

Claiming "fully accessible" or "100% WCAG compliant" — overclaiming can be used against you. State your target and honest status.
No working feedback channel. An ignored contact address is worse than none.
Never updating the review date.

Generate one in seconds

Use the free accessibility statement generator to produce a tailored statement, then back it with continuous scans so the status line stays true. A statement that claims conformance you cannot show is a liability; one backed by dated audits is an asset.

Originally published on access-proof.com.

PDF Accessibility: How to Make PDFs WCAG Compliant

Romain — Fri, 22 May 2026 07:26:50 +0000

WCAG and the ADA apply to document content, not just HTML pages. A scanned, untagged PDF is invisible to a screen reader — and PDFs (statements, guides, forms) are often the most important documents on a site. Here is how to make them conformant.

Why PDFs are an accessibility blind spot

Teams audit their web pages and forget the PDFs linked from them. But a fee schedule, a benefits guide, or an application form in PDF is subject to the same WCAG criteria. An untagged PDF fails WCAG 1.3.1 (Info and Relationships), 1.1.1 (Non-text Content), and more.

The checklist

Tags and reading order

The PDF must have a tag tree that reflects the logical reading order. This is the single most important fix — it is what lets a screen reader navigate headings, paragraphs, and lists.

Document structure

Use real heading tags (H1, H2, H3) in order, real lists, and real paragraphs — not just visually styled text.

Alt text on images

Every informative image needs alternative text; decorative images are marked as artifacts so they are skipped.

Tables

Data tables need header cells defined so screen readers can associate each value with its row and column.

Document language and title

Set the document language (so the screen reader uses the right pronunciation) and a descriptive document title in the metadata.

Forms

PDF form fields need labels (tooltips), a logical tab order, and accessible instructions.

Color and contrast

Same thresholds as the web: 4.5:1 for normal text. Never use color alone to convey meaning.

How to check a PDF

Adobe Acrobat Pro has a built-in Accessibility Checker (Prepare for accessibility). The free PAC (PDF Accessibility Checker) tests against PDF/UA and WCAG. Always finish with a manual screen-reader pass — tags can be present but illogical.

The better long-term fix

Where you can, publish content as HTML instead of PDF. HTML is accessible by default when authored correctly, reflows on mobile, and is far easier to keep conformant than a binary document.

How AccessProof helps

AccessProof audits the HTML pages of your site and flags where PDF downloads are linked, so you can route those documents into a PDF remediation workflow. For the web layer itself, a free scan shows your current WCAG status in under a minute.

Originally published on access-proof.com.

Image Alt Text: WCAG Rules and Best Practices

Romain — Fri, 22 May 2026 07:21:09 +0000

Alt text (the alt attribute on images) is how screen readers describe pictures to people who cannot see them. It satisfies WCAG 1.1.1 Non-text Content (Level A) — the most fundamental accessibility rule. Getting it right is mostly about context, not description.

WCAG 1.1.1 in one sentence

Every non-text element that conveys information needs a text alternative that serves the equivalent purpose. Decorative elements need an empty alternative so assistive tech skips them.

The four kinds of images

Informative

Conveys meaning. Alt text describes the information, not the picture. For a chart showing rising sales, use alt="Sales up 24% from Q1 to Q2", not alt="bar chart".

Decorative

Adds no information (background textures, dividers, eye-candy). Use alt="" — empty, not missing — so screen readers skip it.

Functional

Inside a link or button. Alt text describes the action, not the icon. A magnifying-glass search button is alt="Search".

Complex

Charts, infographics, maps. Use a short alt for the gist plus a longer description nearby — a caption, adjacent text, or a linked data table.

Rules that catch most failures

Never start with "image of" or "picture of" — the screen reader already announces "image".
Do not keyword-stuff. Alt text is for users, not bots (good alt text helps SEO honestly anyway).
Logos: the alt text is the company name, e.g. alt="AccessProof".
If the same information is in adjacent text, the image is decorative — use an empty alt.
Text in images: the alt must contain the exact text (and avoid text-in-images where you can).

Quick examples

ImageBad altGood alt

Team photo on About page"team""The AccessProof team at the 2026 a11y summit"

PDF download icon link"icon""Download the WCAG checklist (PDF)"

Decorative section divider"divider line"empty alt

How AccessProof helps

AccessProof flags every image missing an alt attribute and every empty alt where the image appears informative — mapped to WCAG 1.1.1, with the exact selector. No tool can judge whether your alt text reads well, but AccessProof guarantees none are missing. Run a free scan to see your image findings.

Originally published on access-proof.com.

How to Do a Website Accessibility Audit (Step by Step)

Romain — Fri, 22 May 2026 07:20:38 +0000

An accessibility audit checks a website against the Web Content Accessibility Guidelines (WCAG). Done well, it produces two things: a prioritized list of issues to fix, and dated evidence that you are actively conforming. Here is the 7-step workflow we use.

Automated scanning catches about 30-40%

Automated tools (axe-core, Lighthouse, AccessProof) reliably catch issues like color contrast, missing alt text, unlabeled form fields, and ARIA misuse. They cannot judge whether alt text is meaningful, whether focus order makes sense, or whether an error message is understandable. A real audit combines automation with manual testing.

The 7 steps

1. Define scope and standard

Pick the pages that represent your templates (home, a content page, a form, a listing, checkout or login). Set your target: WCAG 2.2 Level AA is the practical standard for ADA and the EAA.

2. Run an automated scan

Scan each template with a WCAG scanner. Export the findings as your baseline and group them by severity — critical and serious first.

3. Test with the keyboard only

Put the mouse aside. Tab through every page. Can you reach and operate every control? Is the focus indicator always visible? Can you escape every menu and modal? Keyboard traps are critical failures automation often misses.

4. Test with a screen reader

Use NVDA (Windows) or VoiceOver (Mac). Listen to the page title, headings, link text, and form labels. Anything that reads as "link" or "button" with no name is a failure.

5. Check contrast and zoom

Verify text contrast (4.5:1 for normal text, 3:1 for large) with a contrast checker. Zoom the browser to 200% and 400% — content must reflow without horizontal scrolling or clipping.

6. Audit forms and error states

Submit forms with empty and invalid data. Are errors announced and tied to the right field? Are required fields and formats communicated in text, not color alone?

7. Document and schedule

Record every finding with its WCAG criterion, the page, and the fix. Then schedule the scan to repeat — the dated record of continuous remediation is what matters legally.

Common mistakes

Running one tool and calling it an audit (you miss the majority of issues).
Auditing only the marketing pages, never the logged-in app where users spend time.
Fixing once and never re-scanning — conformance drifts with every deploy.
Trusting an overlay widget to "fix" issues. Courts increasingly reject them.

How AccessProof helps

AccessProof automates steps 2, 5, and 6 with the axe-core 4.9.1 engine, prompts you for the manual checks in steps 3-4, and archives each scan as a timestamped PDF — so step 7 happens by default. Schedule weekly or per-deploy scans and your audit trail builds itself.

Originally published on access-proof.com.

The Shopify Store Accessibility Checklist (WCAG 2.2)

Romain — Tue, 19 May 2026 18:42:52 +0000

Shopify's Dawn theme (and most marketplace themes) ships with several WCAG 2.2 issues out of the box. Here's a checklist we use when auditing Shopify stores, in priority order.

Critical (fail an audit on their own)

Color contrast on sale price tags (red on light pink), placeholder text in inputs, and the cart drawer headers. Threshold: 4.5:1 normal text, 3:1 large/bold.
Buttons without accessible names: the icon-only quantity steppers (+ / −) often have no aria-label.
Form labels on the checkout: most "floating label" implementations fail when the label moves outside the input's accessible name.

Serious

Carousel autoplay with no pause control.
Keyboard trap in the predictive search drawer (focus stays inside even after closing).
Modal product quick-view returns focus to the top of the page instead of the trigger.

WCAG 2.2-specific

Target size 2.5.8: social icons in the footer are typically 16×16. Bump to 24×24 minimum.
Drag movements 2.5.7: any custom slider or sortable wishlist needs a click/tap fallback.
Accessible authentication 3.3.8: Shopify's default checkout is fine; custom checkouts that ban paste in the password field fail this.

Quick wins

Audit your theme.liquid for hardcoded colors against your background tokens.
Add aria-label to every `` that contains only an icon or SVG.
Set focus styles globally: :focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
Test the keyboard tab order through a full checkout. If you can't complete a purchase keyboard-only, the score doesn't matter.

AccessProof scans Shopify stores out of the box (we follow redirects through the storefront) and groups findings by template so your dev team can fix them theme-wide instead of page-by-page.

Originally published on access-proof.com.

axe-core vs. Lighthouse: Which Catches More Accessibility Issues?

Romain — Tue, 19 May 2026 18:42:21 +0000

Lighthouse and axe-core are the two automated accessibility scanners most teams reach for. They share a heritage (Lighthouse's a11y category embeds axe-core), but they catch different things in practice. We ran both against 50 production websites — here's what we found.

The setup

50 sites, mix of e-commerce, SaaS, and content (avg 8 issues/site between the two).
Lighthouse 11 (default a11y category, mobile preset).
axe-core 4.9 with rules at wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa.

Results

MetricLighthouseaxe-core 4.9

Avg issues found per site4.27.8

Unique rules triggered2756

WCAG 2.2 coveragepartialfull

False positive rate (manual review)~5%~3%

What axe-core catches that Lighthouse misses

WCAG 2.2 target-size violations (2.5.8).
ARIA misuse on custom widgets (axe is much stricter on role/state mismatch).
Region/landmark issues on complex layouts.
Color contrast on text inside images (axe has better OCR-aware checks).

What Lighthouse adds

Performance correlation: an accessibility score next to LCP/CLS gives leadership a single dashboard.
Crawl-style scoring out of 100, easier to track over time at a high level.

Verdict

Use both. Lighthouse is great for tracking a top-line score in CI dashboards. axe-core is what you want when you need to fix issues — its rule set is broader, its node-level reporting is more actionable, and it's the engine behind most professional audits. AccessProof runs axe-core under the hood, mapped to WCAG 2.2 and exportable as PDF.

Originally published on access-proof.com.