Canceling a subscription is, by design, meant to be harder than starting one. Most products route a cancellation request through at least one retention screen, a discount offer, a pause option, a "tell us why you're leaving" survey, before the account is actually closed. That friction is a deliberate product and business decision, and reasonable people disagree about how much of it is fair. What is not a matter of opinion is whether that friction is possible to get through at all if you cannot use a mouse. We tested 25 different consumer and SaaS subscriptions, attempting to cancel each one using a keyboard alone. Nineteen of the twenty-five retention flows contained at least one screen that functioned as a genuine keyboard trap, a point where focus could not be moved forward, backward, or out, with no way to proceed or exit without a mouse click.
This is a distinct and more severe failure than most accessibility gaps covered elsewhere on this site. A missing alt attribute or an unlabeled icon makes a page harder to use. A true keyboard trap makes a specific action impossible to complete for anyone who cannot click, full stop, and WCAG treats this category of failure differently for exactly that reason.
The Standard: WCAG Success Criterion 2.1.2 No Keyboard Trap is a Level A requirement, the lowest and most fundamental conformance level defined, precisely because trapping keyboard focus makes an interface completely non-functional rather than merely harder to use.
The Three Ways the Trap Actually Happened
The specific mechanism varied across the nineteen failures, but grouped into three recurring shapes. The first and most common was a modal dialog offering a discount or pause option that appeared over the cancellation flow, where Tab moved focus into the modal but then continued cycling past it into hidden or inert page content behind the modal instead of looping back within the modal itself, and no keyboard-accessible close control existed inside the modal's own focus order. A user could tab endlessly through invisible background elements and never reach a way to decline the offer and proceed.
The second was a multi-step survey, "tell us why you're canceling," where a required radio button or dropdown field could be focused but not actually selected using Space or arrow keys, meaning the "continue" button remained permanently disabled because the required field could never be completed by keyboard, with no skip option available.
The third, and the most clearly deliberate-feeling of the three, was a confirmation screen where a small, low-contrast "no thanks, cancel anyway" text link existed as the only path forward, positioned outside the normal tab order entirely, reachable only by a mouse click precisely placed on that specific text, while a large, prominently styled "keep my subscription" button was fully keyboard accessible and appeared first in the tab sequence.
Why the Third Pattern Deserves Separate Scrutiny
The first two failure types read as genuine engineering oversights, a modal built without proper focus containment, a required field built with a custom control that never got full keyboard support. The third pattern, a fully keyboard-operable "keep subscription" path paired with a genuinely unreachable "cancel anyway" link, is harder to explain as an accidental gap, because it required the retained action to work correctly while the canceling action specifically did not. Whether or not that asymmetry was intentional in each individual case, the effect is the same regardless of intent: a keyboard-only user is functionally unable to complete the one action, canceling, that the interface's own business incentive runs counter to.
This overlaps with a related legal question covered in our piece on why a cookie banner's keyboard trap is also a consent violation: once an interface's inaccessibility starts to specifically block a legally or financially disadvantageous-to-the-business action while leaving the favorable action fully accessible, that pattern moves closer to the territory regulators and courts increasingly scrutinize as a dark pattern, not just an accessibility bug, even though the WCAG violation itself is identical regardless of the company's motive.
The Regulatory Angle Beyond Accessibility Law
Several jurisdictions have separately moved to require that canceling a subscription be no harder than signing up for one, a principle sometimes summarized as "click to cancel." A retention flow that happens to also be a keyboard trap sits at the intersection of two different compliance obligations at once: the WCAG keyboard requirement, and consumer protection rules aimed specifically at making cancellation friction-free. A company defending its retention flow's difficulty as a legitimate business practice still has to contend with the fact that, for keyboard users, "difficult" was not the actual experience. "Impossible" was.
What to Test on Your Own Cancellation Flow
If your product has any retention or save flow between a user clicking "cancel" and their subscription actually ending, that flow needs a dedicated keyboard-only test, independent of any general accessibility testing done elsewhere in the product. Specifically: can every offer be declined using only Tab and Enter, does any modal correctly trap and then release focus rather than leaking into background content, and is the final cancel action actually reachable in the normal tab order rather than hidden as a mouse-only link. This is the same category of test covered in our multi-step form wizard accessibility guide, applied specifically to the highest-friction flow most subscription products intentionally build.
Our team can test your actual cancellation and retention flow and tell you whether it contains a real keyboard trap. Reach us at experts@wcag.world, or review WCAG's No Keyboard Trap guidance and the FTC's negative option rule for the standards and consumer protection rules this pattern intersects with.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: request the relevant WCAG review.