Skip to main content
Back to all posts

Accessibility Testing for Startups: API-First on a Budget

Benjamin Morton

Most founders assume web accessibility lawsuits are a big-company problem. The data says the opposite: in 2025, 64% of companies sued over web accessibility had under $25 million in revenue (UsableNet, 2026). Small and mid-size businesses aren't the exception among defendants; they're the majority.

The good news for a startup is that the cost of doing something about it is close to zero. You can stand up a genuine, automated accessibility process for $0, catch the bulk of issues before they ship, and spend real money only when you actually need to. This guide covers the risk, the free stack, and a phased plan that fits a team with no accessibility specialist and no budget line for one.

Key Takeaways

  • You're a target: 64% of companies sued for web accessibility in 2025 had under $25M revenue (UsableNet, 2026).
  • A startup can run a full automated accessibility gate for $0: eslint-plugin-jsx-a11y + axe-core + Lighthouse in GitHub Actions.
  • Prevention is cheap, retrofit isn't: reactive accessibility adds about 15% to a project; building it in drops that to 5% or less (Deque, 2024).
  • Automate the roughly half of issues a scanner catches, and reserve manual testing for your signup and checkout flows.

Are Startups Actually at Risk?

Yes, and more than most founders think. Plaintiffs filed 3,117 federal website accessibility lawsuits in the US in 2025, up 27% on the year and 36% of all ADA Title III filings (Seyfarth Shaw, 2026). The targets skew small: 64% of the companies sued had revenue under $25M, and 46% of federal cases were against repeat defendants (UsableNet, 2026).

Who Gets Sued for Web Accessibility? 64% under $25M 36% over $25M Share of companies sued for web accessibility in 2025, by annual revenue. "Too small to be a target" is a myth. Source: UsableNet, 2026.

Europe adds a second front. The European Accessibility Act has been enforceable since June 2025, and its microenterprise carve-out is narrower than people assume. It exempts only businesses with fewer than 10 employees and under €2M turnover, and even then from many of the Act's requirements rather than all of them (Greenberg Traurig, 2025). The relief is aimed at the smallest businesses, and any startup planning to grow will cross that threshold fast, so it's not a strategy. Our EAA developer guide covers who's actually covered, including how the rules treat services and products differently.

Citation capsule: Web accessibility litigation is not just a large-enterprise risk. Of the companies sued over web accessibility in the US in 2025, 64% had annual revenue under $25 million, and 46% of federal cases targeted repeat defendants, across 3,117 federal filings (UsableNet; Seyfarth Shaw, 2026). Small and mid-size businesses make up the majority of defendants, not the exception.

What Does Accessibility Cost If You Wait?

More than doing it now, and the gap is large. Deque's analysis puts reactive accessibility, bolting it on after the fact, at roughly a 15% premium on a project, against 5% or less when you build it in from the start (Deque, 2024). On a $500,000 build, that's the difference between $75,000 and $25,000.

The Cost of Waiting (on a $500K project) ~$75K Retrofit (15%) ≤$25K Shift-left (≤5%) Reactive accessibility adds ~15% to a project; building it in from the start, 5% or less. Source: Deque, 2024.

That's before litigation. Publicly reported settlements are scarce (most are confidential), but the commonly cited range for a web accessibility claim runs from a few thousand dollars in settlement to tens of thousands once defense costs are counted. Treat those figures as directional rather than precise, since there's no rigorous public dataset. The point stands either way: a CI check that costs nothing is cheaper than any of it. For the scale of the underlying problem, our web accessibility statistics show 95.9% of home pages still have detectable failures.

The $0 Startup Accessibility Stack

Here's the part that surprises people: a startup can run a complete automated accessibility gate without paying for anything. Every tool below is free, and together they catch the high-volume failures that make up the bulk of real-world errors.

Tool

Cost

What it does

eslint-plugin-jsx-a11y

Free (MIT)

Flags accessibility mistakes in JSX as you type

axe-core

Free (MPL-2.0)

The automated engine; run it in your tests and CI

Lighthouse

Free

A quick per-page audit built into Chrome

pa11y / pa11y-ci

Free (LGPL-3.0)

Command-line scanning designed for CI

axe DevTools extension

Free

Manual per-page checks in the browser

GitHub Actions

Free (public repos; 2,000 min/month on private)

Runs the gate on every pull request

Wire two of them into CI and you have a real gate. A scan on every pull request means an accessibility regression can't be merged, not just that it's visible somewhere:

# .github/workflows/a11y.yml
- name: Accessibility scan
  run: npx pa11y-ci --sitemap https://staging.example.com/sitemap.xml

The full CI setup, including gating on axe-core and failing the build on new violations, is in our GitHub Actions accessibility guide. The only place free stops is guided manual testing and org-scale monitoring: axe DevTools Pro (around $40 to $100 per seat per month, per third-party estimates) adds guided tests, and enterprise suites are quote-based. Our free vs paid tools comparison covers exactly when that's worth it, and the full tool landscape maps the rest. For a seed-stage startup, paid usually isn't worth it yet.

Why API-First Testing Fits a Startup

Because the expensive part of accessibility is human time, and automation lets you spend it wisely. Automated tools catch roughly half of accessibility issues by volume, and crucially they catch the high-frequency ones (contrast, missing labels, bad ARIA) that scanners detect reliably. Running that check as an API or CLI call on every build shifts detection left, so those issues never reach production.

From building a scanner, the single highest-leverage move for a small team isn't buying a better tool; it's making the check a build gate. A scanner that emails you a report gets ignored under deadline pressure. A scanner wired into CI that fails the pull request changes what can even be merged. That's why we built a11yFlow as an API: so a startup can add "is this accessible?" to its pipeline with one HTTP call, and reserve its scarce manual and expert-testing budget for the things automation is blind to, the keyboard flow, the focus order, whether the alt text actually describes the image.

A Phased Accessibility Roadmap

You don't do all of this at once. Sequence it so week one is cheap and each phase builds on the last, following the W3C's Initiate, Plan, Implement, Sustain model (W3C WAI):

  1. Week 1 (near-zero effort). Add eslint-plugin-jsx-a11y to your linter so mistakes surface as you type. Run the free axe DevTools extension over your five most important pages. Write a one-page policy: "we target WCAG 2.2 AA." That policy is the plan everything else hangs off.
  2. Weeks 2 to 4 (automate the floor). Add axe-core or pa11y-ci to GitHub Actions as a pull-request gate, and set a Lighthouse accessibility budget so scores can't regress. Now the common failures can't ship.
  3. Quarterly and before major launches (spend the human time). Bring in manual and screen-reader testing on the flows that matter most: signup, checkout, the core loop. This is where automation is blind and where a lost customer actually costs you, so it's where a person should look.

That's it. No specialist hire, no enterprise contract, and most of the risk retired for the price of some CI minutes.

Frequently Asked Questions

Do startups really get sued for accessibility?

Yes, disproportionately. 64% of companies sued over web accessibility in 2025 had under $25M in revenue, and 46% of federal cases were repeat defendants, across 3,117 federal filings (UsableNet; Seyfarth Shaw, 2026). Small and mid-size businesses are the majority of targets, not an exception.

Is my startup exempt from the European Accessibility Act?

Probably not for long. The EAA's microenterprise exemption applies only to businesses with fewer than 10 employees and under €2M turnover, and only relieves them of many of the Act's requirements (Greenberg Traurig, 2025). It's aimed at the smallest businesses, and any startup planning to grow past that size shouldn't rely on it.

How can I test accessibility for free?

Combine eslint-plugin-jsx-a11y (editor), axe-core or pa11y-ci (CI), and Lighthouse (per-page), all free, gated in GitHub Actions (free on public repos, 2,000 minutes/month on private). That stack catches the high-volume failures that account for most detected errors (WebAIM Million, 2026). Add manual testing for critical flows.

When should a startup pay for accessibility tools?

When you need what automation can't give you: guided manual testing to push coverage past ~57%, continuous monitoring across many pages, or VPAT/ACR reports for enterprise procurement. Until then, the free stack plus manual testing of your critical flows is enough. Our free vs paid comparison breaks down the boundary.

The Bottom Line

Being small is not protection. The majority of web accessibility lawsuits land on companies under $25M in revenue (UsableNet, 2026), and retrofitting accessibility later costs roughly three times what building it in does (Deque, 2024). For a startup, that's a strong argument to start now, when it's cheapest.

And starting is genuinely free. Lint in the editor, axe-core or pa11y in CI, a Lighthouse budget, and a one-page WCAG 2.2 AA policy cost nothing but an afternoon, and they retire most of the risk. Automate the common failures on every pull request, test your signup and checkout by hand each quarter, and pay for tooling only when growth forces the question. If you want the CI step to be a single API call, that's exactly what a11yFlow is built for.

Sources

PreviousHow Accessibility Scores Are Calculated (Lighthouse, axe, Custom)
NextFree vs Paid Accessibility Testing Tools: A Feature Matrix