Digital Accessibility Lawsuits Are on Pace for a Record 6,000 in 2026 — And Cancellation Flows Are Built to Fail Them

Most cancellation-flow audits look for the same handful of things: how many clicks to cancel, whether the retention offer is relevant, whether the copy nudges too hard. Almost nobody runs the flow with a mouse unplugged, and almost nobody turns on a screen reader before shipping it. That gap used to be a minor accessibility debt most SaaS teams could defer indefinitely. It isn't anymore — digital accessibility litigation just had its highest-volume half-year on record, and a cancellation modal happens to combine nearly every UI pattern that fails.

The litigation trend isn't slowing down, it's accelerating

UsableNet has tracked digital accessibility litigation for close to a decade, and its 2026 midyear numbers describe the busiest six months the firm has ever recorded — not a plateau, an acceleration. Plaintiffs filed 4,928 web accessibility lawsuits in 2025 across federal and state courts; 2026 is tracking 20-25% above that pace, which puts the full-year number somewhere close to 6,000.

Source: UsableNet, 2026 Midyear Digital Accessibility Lawsuit Report.

Two details in that table matter more than the headline count. First, the defendant pool is widening past the retail sites everyone assumes are the target — healthcare, financial services, and hospitality are now named categories, and none of those are further from "self-serve SaaS with a billing portal" than ecommerce is. Second, and more relevant if you've assumed litigation risk scales down with company size: the share of defendants with over $25 million in revenue has climbed three years running. Plaintiffs' firms are increasingly filing against companies with the revenue to settle rather than fight, which is a very different risk profile than "this only happens to huge retailers."

Why a cancellation flow specifically fails

A cancel flow isn't a static page — it's the single most interaction-dense screen in most SaaS products. In the space of one flow you typically get a modal dialog, an icon-only close button, a reason-select dropdown or radio group, a retention offer with its own accept/decline buttons, and a final confirmation step. Each of those is a distinct WCAG success criterion, and each is disproportionately represented in the failure data researchers actually measure at scale.

WebAIM's annual Million report — an automated scan of the top one million home pages, now in its seventh year — found that 95.9% of pages have at least one detectable WCAG failure, averaging 56.1 errors per page, up 10.1% from the year before. That's the first year-over-year regression after six straight years of gradual improvement. Six categories account for 96% of every error WebAIM finds, and the ranking hasn't changed in seven years:

Look at that list against a typical cancel modal and the overlap is almost total. Low-contrast text is the single most common failure anywhere on the web, and cancel flows are full of exactly the kind of deliberately de-emphasized copy — "no thanks, keep my plan" links, fine-print renewal disclosures, muted secondary buttons — that designers intentionally style at low contrast to steer attention toward the option they'd rather you pick. Unlabeled form inputs shows up the moment your cancellation-reason field is a styled dropdown or radio group built without an associated `<label>` or `aria-label`. Empty buttons and links are what you get from an icon-only "×" close button with no accessible name — a pattern used in nearly every modal-based cancel flow we've seen.

Mapping cancel-flow patterns to the WCAG criteria they break

None of these are exotic edge cases. A keyboard trap inside a modal is one of the most frequently cited failures in accessibility litigation generally, precisely because it's binary and easy to demonstrate: either Escape and Tab-out work, or a keyboard-only user is stuck on your cancel screen with no way forward and no way back. If your only way out of that state is refreshing the page, you've just forced someone who was trying to leave your product to instead lose whatever else they had open in that tab.

Why this is worse than a generic accessibility gap

Every page on your site probably has some WCAG debt — that's true of 95.9% of the web, per WebAIM, so you're not unusual. What makes a cancellation flow specifically higher-risk than, say, your marketing homepage is the combination of legal exposure and product exposure landing on the same screen at the same time.

The legal exposure is what this whole piece has been about. The product exposure is the part that should worry a churn-focused team even without a lawyer in the room: a subscriber who can't complete a self-serve cancellation because a modal trapped their keyboard focus doesn't give up on leaving — they call support, or they dispute the next charge as a chargeback. We've covered that exact failure mode in our guide to refund policy and chargebacks, and it applies just as directly here: an inaccessible exit doesn't reduce churn, it just reroutes it into a more expensive channel. It's the same mechanism our research on dark patterns in cancellation flows found for deliberately obstructive design — the difference is that an accessibility failure is usually unintentional, which doesn't make the outcome, or the legal exposure, any different.

It also sits directly next to the compliance work most SaaS teams are already doing. If you've implemented the FTC's click-to-cancel requirements or the EU's withdrawal button, you've already built the "cancellation must be at least as easy as signing up" symmetry those rules require. None of that symmetry matters to a screen reader user if the modal that delivers it can't be operated without a mouse.

What to actually fix, in order

You don't need a full accessibility audit to materially reduce risk on this one screen. Four fixes cover most of what shows up in both the litigation data and the WebAIM error list, and none of them require a redesign:

• Give every icon-only button an accessible name. An aria-label="Close cancellation dialog" on your "×" button takes one line and directly fixes the single most common failure pattern in modal-based flows.
• Trap focus correctly, not accidentally. A modal should move focus inside itself when it opens, cycle Tab between its own focusable elements, close on Escape, and return focus to whatever the user clicked to open it. That's a deliberate, bounded focus trap — different from the accidental kind where focus gets stuck with no exit at all.
• Check contrast on every "de-emphasized" element on purpose. Muted colors used to steer attention away from the cancel button are exactly where contrast ratios fall below the 4.5:1 minimum for normal text (3:1 for large text) that WCAG AA requires. Run your actual hex values through a contrast checker rather than eyeballing it.
• Label every form control programmatically. A cancellation-reason field needs a real <label> or aria-label tied to it via for/id or aria-labelledby — not just placeholder text or a visually adjacent heading, neither of which a screen reader reliably associates with the input.

Test the result two ways before you consider it done. First, unplug your mouse and complete the entire flow — open the modal, select a reason, respond to any retention offer, confirm cancellation — using only Tab, Shift+Tab, Enter, and Escape. Second, turn on a screen reader (VoiceOver on Mac is Cmd+F5, NVDA on Windows is free) and do the same thing with your eyes closed. Automated tools like axe DevTools or Lighthouse's accessibility panel catch roughly a third of WCAG failures in seconds and are worth running first, but they can't tell you whether your focus order makes sense or whether a screen reader announcement is actually meaningful — that part still needs a human pass.

Accessibility work on a cancel flow tends to get deprioritized because it looks like pure cost with no upside metric attached to it. The litigation numbers above are one reason that calculus is changing, but the more durable reason is simpler: a subscriber who can complete a self-serve cancellation, cleanly, on the first try, is a subscriber whose data you can trust and whose next renewal decision you might still win. CancelFlow's flow is built on standard, keyboard- and screen-reader-operable components for exactly this reason — the goal was never to make leaving harder to reach, just to make sure the right offer is there when someone does.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.