More than 5,000 ADA digital accessibility lawsuits were filed in 2025, up from over 4,000 the year before (UsableNet, 2026). Meanwhile, the European Accessibility Act started enforcement in June 2025, with fines reaching up to EUR 1,000,000 in some member states (Fieldfisher, 2025). The regulatory window for treating accessibility as optional has closed.
Yet most developers still face the same three bad choices: enterprise tools that start at five figures, credit-based APIs with unpredictable costs, or building and maintaining their own Playwright + axe-core infrastructure. a11yFlow is our answer to that. This post covers what it does, how the API works, and what is on the roadmap.
If you're weighing options, see our guide to comparing accessibility testing tools.
TL;DR: a11yFlow runs WCAG 2.2 audits via a single HTTP request: no browser infrastructure, no enterprise contract, no credit maths. Submit a URL, poll for the result, get violations with impact ratings and code-level fix guidance. There is a free tier, and scheduled monitoring, webhooks and a GitHub Action are on the roadmap.
Why We Built It
The web is failing its users at scale: 94.8% of the top one million homepages have detectable WCAG failures, averaging 51 errors each (WebAIM Million, 2025). Meanwhile the legal floor keeps rising, with US digital accessibility filings exceeding 5,000 in 2025 and the European Accessibility Act now in force.
We are not going to re-argue that case here, because we have already made it properly elsewhere. If you want the evidence rather than the summary:
- The failure rates, and which of the widely-quoted numbers survive scrutiny: web accessibility statistics
- What automated scanning does and does not catch: automated vs manual accessibility testing
- What litigation actually costs, and who gets sued: ADA website lawsuits
- Why overlay widgets increase legal exposure rather than reduce it: why accessibility overlays fail
What none of those posts solved is the tooling problem. Developers who want to act on any of it face the same three bad options: enterprise platforms that start at five figures, credit-based APIs with costs you cannot predict, or building and maintaining your own Playwright and axe-core infrastructure. a11yFlow exists to remove that third option by making it a single HTTP request.
How Does API-Based Accessibility Scanning Work?
API-based scanning removes the infrastructure burden. Instead of running headless browsers locally, you send an HTTP request with a URL and receive structured WCAG violation data in JSON. A study by Applause found 73% of organizations aren't adequately equipped for ongoing accessibility testing (Applause, 2024), an API approach closes that gap without adding operational complexity.
Here's the workflow in three steps.
Step 1: Get an API Key
curl -X POST https://api.a11yflow.dev/v1/keys \
-H "Content-Type: application/json" \
-d '{"email": "you@example.com"}'Step 2: Submit a URL for Scanning
curl -X POST https://api.a11yflow.dev/v1/scans \
-H "Authorization: Bearer sk_live_your_key_here" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com"}'Step 3: Retrieve Results
curl https://api.a11yflow.dev/v1/scans/scan_id_here \
-H "Authorization: Bearer sk_live_your_key_here"Scans typically complete in 5 to 15 seconds. The response includes every violation with its WCAG criterion, impact level, failing element selector, XPath, contrast ratios where relevant, and a specific fix suggestion.
After building and maintaining our own Playwright + axe-core infrastructure for over a year, the pain points became clear: browser dependency management in CI, flaky headless Chrome processes, and the constant overhead of keeping scan workers healthy. Wrapping that complexity behind an API call was the obvious next step.
The key difference from browser extensions or CLI tools? An API fits into any workflow. Pipe results into your CI/CD pipeline, issue tracker, Slack channel, or custom dashboard. No plugins, no browser dependencies, no local setup.
For the full endpoint reference, see the API documentation.
Citation capsule: 73% of organizations lack adequate tooling for ongoing accessibility testing (Applause, 2024). API-based scanning addresses this by accepting a URL via HTTP request and returning structured WCAG violation data in JSON, removing the need for local browser infrastructure or manual audit scheduling.
What's on the Roadmap?
A11yFlow launched with core scanning capabilities, but the roadmap targets the gaps developers ask about most. Here's what's coming:
- Scheduled monitoring, set a scan cadence and receive alerts when your accessibility score drops below a threshold
- Webhooks, trigger actions in your own systems (Slack, Jira, PagerDuty) when scans complete
- GitHub Action, run WCAG checks on every pull request without custom workflow configuration
- Public rule pages, a searchable reference for every axe-core rule with code-level fix guidance
These priorities came directly from early adopter feedback during the beta period. Scheduled monitoring was the most requested feature by a wide margin, followed by CI/CD integration via GitHub Actions. We're building what developers told us they need, not what looks good on a feature comparison chart.
Check the full API documentation for endpoint details.
Frequently Asked Questions
How is API-based scanning different from browser extensions?
Browser extensions require manual interaction, you open a page, click a button, review results. API-based scanning accepts a URL via HTTP request and returns structured JSON. This makes it automatable: you can integrate scans into CI/CD pipelines, cron jobs, or monitoring dashboards without human intervention. Extensions work well for spot checks during development; APIs work for systematic, repeatable testing at scale.
What WCAG standards does the scanner cover?
The scanner uses axe-core, whose rule set covers WCAG 2.0 A/AA, WCAG 2.1, and WCAG 2.2 criteria. Every scan tests against the full rule set. Results include the specific WCAG success criterion each violation relates to, so you can map findings directly to compliance requirements. See the full rule reference in the API documentation.
Can automated scanning replace a manual accessibility audit?
No. Automated tools detect roughly 57% of accessibility issues by volume (Deque, 2021). Keyboard navigation, reading order, cognitive clarity, and meaningful content evaluation still require human testers, ideally people who use assistive technology daily. Automated scanning is a filter that catches the majority of common violations before they reach users. Manual audits cover the rest.
Is there a free tier?
Yes. The free plan includes 25 scans per month with no credit card required and no expiration. Every feature is available at every tier, there are no artificial limits on what data you can see. Check the pricing plans for details on higher-volume options.
How long does a scan take?
Most scans complete in 5 to 15 seconds. Each scan launches headless Chromium via Playwright, fully renders the page (including JavaScript-driven SPAs and client-rendered content), then runs axe-core against the rendered DOM. You poll the scan endpoint until results are ready, or set up webhooks to receive a notification on completion.
Do accessibility overlays count as compliance?
No. Courts have not accepted overlay widgets as evidence of WCAG compliance. In 2024, 25% of ADA lawsuits involved sites with overlays installed (Accessibility.works, 2025). Overlays modify visual presentation without fixing underlying HTML structure. The only path to compliance is fixing the code, which starts with identifying what's broken through automated and manual testing.