Keyboard Trap Rate: The Metric That Finds What Your Scan Score Hides

Aggregate accessibility scores have a smoothing problem. A store can post a respectable overall number while its checkout contains a modal that swallows keyboard focus and never gives it back. The average looks managed. The user inside the modal is not managed at all. They are stuck, and stuck at checkout has a legal name and a revenue name.

Keyboard trap rate cuts through the smoothing. Count your key templates. Test each one for traps: any component where focus can arrive by keyboard and cannot leave by keyboard. Report the share of templates with at least one trap. The number is small, brutal, and impossible to argue with in a steering meeting.

What counts as a trap

A trap is any element or component that captures focus without a keyboard exit: modals with no escape route or close control reachable by keyboard, embedded widgets and iframes that take focus and keep it, custom carousels and menus that cycle focus internally forever. WCAG 2.1.2 No Keyboard Trap is a Level A criterion, the floor of the floor. Failing Level A on your highest value template is the finding. Everything else is commentary.

Distinguish traps from long paths. A page that takes eighty tabs to cross is a focus order and efficiency problem. A page where tab eighty one stops working is a trap. Both deserve fixing, but they are different severities and different conversations, and metrics that blend them hide the emergency inside the inconvenience.

Testing traps is manual, and that is the point

Scanners are weak here because a trap is a behaviour, not a markup pattern. Your metric therefore rests on a short, disciplined manual protocol: keyboard only, through every interactive component on the template, including cookie banners, chat widgets, modals, video players and payment frames. Note where focus enters, whether it can leave, and whether the exit is discoverable.

Run it per template, not per URL sample. Traps live in components, and components live on templates. One checkout template, one product template, one account template: test the set, publish the trap rate across them, and retest on every component release. The metric stays honest because the population stays defined.

Weight the metric by consequence

Report trap rate raw and weighted. A trap on a marketing landing page is a failure. The same trap in checkout, account creation, or a patient or customer portal is a failure at the exact point where the user cannot choose another door. Weighting by template criticality stops teams from clearing the metric on easy pages while the payment modal keeps its teeth.

This is where the metric earns its keep against the aggregate score. Put both numbers in the same report, every time. When the score rises and trap rate does not move, the report is telling you the programme is polishing the visible and leaving the blocking. Believe the trap rate.

Fixing traps is component work

The durable fix is a focus management standard in the design system: every modal traps focus deliberately while open and returns it on close, with Escape always live; every third party widget is sandbox tested for focus entry and exit before it ships; no component merges without a keyboard walkthrough.

Add trap checks to release gates for the components that historically trap: dialogs, menus, media embeds, payment iframes, chat. Traps regress because components get redesigned for visual reasons by people who never tab through their own work. The gate is cheaper than the demand letter.

Related reading

These earlier guides go deeper on connected questions: Form Label Coverage: A Metric That Counts Labels and Misses Meaning, Contrast Failure Rate: The Metric Lies When the Denominator Moves, and Keyboard Trap Count: The Metric That Should Always Read Zero.

Frequently asked questions

What WCAG criterion covers keyboard traps?

WCAG 2.1.2 No Keyboard Trap, a Level A success criterion. If keyboard focus can be moved to a component, it must be possible to move it away using only the keyboard. Level A is the minimum tier, so a trap is among the most serious findings an audit can report on any page.

Can automated scanners detect keyboard traps?

Only poorly. A trap is an interaction behaviour that emerges when a real user tabs through a component, including third party widgets and payment frames. Scanners can flag suspicious patterns, but a reliable trap rate comes from a defined manual protocol run per template and repeated after component changes.

How is trap rate calculated?

Divide the number of tested templates containing at least one confirmed trap by the total templates tested, and report it alongside a criticality weighted view. The population must stay fixed and named, such as checkout, product, cart, account and content templates, or the rate can be gamed by adding easy templates.

What is the most common trap in ecommerce?

Modal dialogs and embedded widgets share the title: cookie banners, discount popups, chat tools and payment iframes that accept focus and offer no keyboard exit. Third party components are repeat offenders because the store team never keyboard tested them before install and does not control their update cycle.