Can a Blind Customer Cancel Their Subscription? The Accessibility Blind Spot Nobody Audits

Every accessibility audit I have seen starts in the same place: the homepage, the product pages, the checkout. That is where the money comes in, so that is where the attention goes.

Almost nobody audits the way out.

Your account settings page. The “Manage plan” screen. The three-step cancellation flow with the confirmation modal and the “Are you sure?” survey. For a customer using a screen reader or navigating by keyboard, that is often where your site stops working entirely — and unlike a broken product page, they cannot just give up and go to a competitor. They have already paid you. They are trying to stop.

This is the part of the site where an accessibility failure stops being an inconvenience and starts looking, to a regulator or a lawyer, like something worse.

Why the cancel flow is different

A customer who cannot use your signup form is a lost sale. Bad, but recoverable — they leave, you never know, life continues.

A customer who cannot use your cancellation flow is a person who is being charged money every month and cannot make it stop. That is a materially different situation, and three things make it worse:

It is a trapped user, not a bounced one. They have no alternative. They cannot switch to a competitor to solve the problem, because the problem is the recurring charge on their card from you.

The workaround has a cost. Told to call support instead? Deaf and hard-of-hearing customers may not be able to. Told to email? That is now days of waiting while the billing date approaches. Every “just contact us instead” fallback moves the burden onto the customer and adds friction that sighted keyboard-free customers never experience. That difference in treatment is the core of most accessibility complaints.

It looks intentional. This is the part that businesses underestimate. A broken hero carousel reads as sloppiness. A cancel button that a screen reader cannot find, sitting at the end of a flow deliberately designed to be discouraging, reads as a dark pattern. Regulators in both the EU and the US have spent the last few years scrutinising subscription cancellation friction generally. An accessibility barrier layered on top of an already hostile flow is not a good look, and you will have a hard time arguing it was an accident.

None of this requires new law to be a problem. Under the European Accessibility Act, consumer-facing digital services in scope have to be accessible — and managing your subscription is part of the service, not an afterthought attached to it. In the US, the ADA claims that reach websites have consistently focused on whether a customer can complete a transaction, and cancelling is a transaction.

The seven things that break

Here is what actually goes wrong, in rough order of how often I find it.

Account settings frequently live inside a dropdown that opens when you hover over an avatar in the corner. Hover is a mouse behavior. If that menu cannot be opened with a keyboard — Enter or Space on a real button, then arrow keys or Tab through the items — a keyboard-only user cannot reach account settings at all. Everything downstream is irrelevant, because they never get in the door.

Screen reader users often navigate by pulling up a list of every link on the page and scanning it. If your cancel control is an icon with no text, it shows up in that list as “link” or “button” or, memorably, as the name of an SVG file. If it says “Manage” or “Options” or “More”, it is technically labeled and practically useless — there may be nine of those on the page.

3. The confirmation modal does not take focus

You click “Cancel subscription”. A modal appears asking if you are sure. Visually, obvious. But if focus stays behind the modal on the page underneath, a screen reader user hears nothing happen. They keep tabbing, land on controls behind the overlay, and have no idea a dialog is waiting. Some will conclude the button is broken and try again — which, on a badly built flow, can fire the request twice.

The modal needs to move focus into itself when it opens, keep focus inside while it is open, close on Escape, and return focus to the button that opened it. Every one of those four is commonly missing.

4. The retention survey blocks the exit

The “before you go, why are you leaving?” step is where a lot of flows fall apart. It is usually a set of radio buttons with a text field, built quickly, and it inherits every classic form problem at once: no real labels, placeholder text instead of labels, a required field that is not announced as required, and an error state shown only as a red border.

A screen reader user submits, hears nothing, and has no idea why the page did not advance. If that survey is mandatory to proceed, an inaccessible survey is a locked door.

5. The confirmation is silent

Cancellation succeeds. A green banner appears at the top of the page saying you are cancelled through the 14th. Focus is still down where the button used to be, the banner was never announced, and the user has no idea whether it worked. Now they are refreshing the page trying to work out whether they are still being charged.

Status messages need to be announced without stealing focus, and the confirmation should also arrive by email so it does not depend on catching a message on screen.

6. Every step has a countdown or a time limit

Some flows put a timer on the retention offer, or expire the session aggressively on billing pages. Screen reader users, people with motor disabilities, and anyone using magnification move through pages more slowly — sometimes several times more slowly. A limit that feels generous when you test it at full speed with a mouse can be impossible for someone reading a page linearly through audio.

7. The last step requires re-authentication that fails

Billing changes often require a password re-entry or a code sent by SMS. This is reasonable security, but it is also where the flow can hit a hard wall: a CAPTCHA with no accessible alternative, a code input split into six separate boxes that fights screen readers and paste behavior, or a two-minute expiry that is too fast for someone typing with a switch device or reading a code aloud from a phone.

Test yours in 20 minutes

You do not need a developer or a paid tool. You need your keyboard and, ideally, twenty minutes of nobody talking to you.

Set up a test account and actually subscribe. Use a real card if the cheapest plan is a few dollars — you are about to cancel it anyway. Testing this on a staging environment with fake data misses things, because staging rarely has the real payment step.

Now put your mouse somewhere you cannot reach it. Behind the monitor. In a drawer. This is the whole test.

From the homepage, use only Tab, Shift+Tab, Enter, Space, arrow keys, and Escape:

  • Log in.
  • Reach account settings.
  • Find the subscription or billing section.
  • Start the cancellation.
  • Get through the confirmation dialog.
  • Complete the retention survey, if there is one.
  • Finish the cancellation.
  • Confirm that it worked.

Write down every point where you got stuck, had to guess, or lost track of where you were. Specifically watch for: focus you cannot see, a dropdown you cannot open, a modal you cannot reach, a button you tabbed straight past, or a moment where pressing Enter did nothing.

Then do it again with a screen reader. On a Mac, VoiceOver is already installed — Command+F5 turns it on. On Windows, NVDA is a free download. Turn your monitor off, or close your eyes if that is easier, and try the same journey by sound. This is unpleasant the first time and enormously clarifying.

Two questions to answer at the end: at every step, did you know what had just happened, and did you know what to do next? If the answer is no anywhere in that flow, you have found a real problem — not a theoretical one.

What to fix first

If your list is long, order it this way:

Blockers before annoyances. Anything that makes it impossible to complete the cancellation outranks everything else. A cancel control you cannot reach by keyboard, a mandatory survey field you cannot fill in, a modal that never receives focus — these are the ones that create both the human harm and the legal exposure.

Add a plain fallback path immediately. While you fix the real problems, publish a documented alternative: a clearly linked, keyboard-accessible page or form that cancels the subscription, or an email address that gets a same-day response. Say so plainly in your help centre and your accessibility statement. This does not discharge the obligation to fix the flow, but it stops the harm today rather than next quarter.

Then reduce the number of steps. The most reliable accessibility fix for a cancellation flow is having less of it. A retention survey that is optional and skippable cannot block anyone. A single confirmation step is far easier to get right than three. Most of the friction in these flows was added to protect revenue, and most of it does not, so this is often an easier internal conversation than it sounds.

Fix the signup flow’s cousins while you are there. Whatever is broken in cancellation — modals without focus management, unlabeled icon buttons, silent status messages — is almost certainly broken in your plan upgrade, payment method update, and address change screens too. They were built by the same people at the same time with the same components. Audit them together.

The uncomfortable framing

Ask this question in your next planning meeting: if a customer with a disability cannot cancel their subscription without calling us, and calling us is not an option for them, what exactly is happening to their money?

You do not need a regulation to find that answer uncomfortable. And it is worth noticing that the cancel flow is the one part of the product that no internal team ever uses, no designer showcases, and no analytics dashboard celebrates — which is precisely why it is broken.

Twenty minutes with your mouse in a drawer will tell you where you stand.

This article is general information, not legal advice. For questions about your specific compliance obligations, consult a qualified lawyer in your jurisdiction.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.