Keyboard Trap Count: The Metric That Should Always Read Zero
Some metrics are dials and some are tripwires. Keyboard trap count is a tripwire: the number of places on a site where a keyboard user can enter a component and cannot leave it by keyboard alone. WCAG 2.1 Success Criterion 2.1.2, No Keyboard Trap, is a Level A requirement, the floor of the floor, and there is no version of a roadmap where fixing some traps this quarter is an acceptable result. One trap in a checkout is not a partial failure. It is a locked door for every keyboard user who reaches it, and the count that matters is zero.
Track it anyway, because what gets counted gets assigned an owner. Report trap count per template and per third party component, not just per site, because traps are almost never written by the team that owns the page. They arrive inside embedded widgets, chat tools, video players, cookie banners, and date pickers, and they leave when the component is replaced or configured, not when a content editor tries harder.
Where traps actually come from
The classic trap is a modal that captures Tab in a loop and provides no working close control reachable by keyboard: an Escape handler that was never wired, a close button that is a clickable div. The modern traps are subtler. A calendar grid that requires arrow keys with no exit key documented. An embedded form in an iframe whose last field tabs into a void the parent page cannot see. A rich text editor or map that takes focus and holds it. Each one passes a mouse based test suite, because a mouse user clicks outside the component and never learns the keyboard door was locked.
Third party scripts deserve their own line in the count. A site can be trap free in January and gain two traps in March because a vendor updated a widget, and nobody changed a line of the site's own code. That is why trap count belongs in a recurring crawl with a date on it, reviewed like uptime, rather than in an annual audit report that describes a site which no longer exists.
Counting it honestly
Automated scanning finds some traps and misses the iframe and interaction dependent ones, so the count needs a manual component: a keyboard walk of every template, every modal, and every embed, done on a schedule, with the walker recording the component and the exact keystrokes that failed. Log traps with the same fields you would give a bug: component, owner, date found, the criterion, and the user task it blocks. A trap inside a cookie banner blocks every task on the site. A trap in a footer widget blocks none. Both count as one in a naive total, and prioritising by blocked task is how a team clears the total fastest where it matters.
Report two numbers: total traps, and traps on transactional paths. Leadership reads the second one. A quarter where the total stalls but the checkout count hits zero is progress worth reporting precisely, not rounding into a percentage that hides it.
The fix is usually configuration, not code
Most traps close with work measured in hours. Wire the Escape key. Make the close control a real button. Set the embed's options to the accessible mode the vendor documents and the procurement process never asked about. Where a vendor cannot fix a trap, that fact belongs in the renewal conversation with a date attached, because an inaccessible third party component is the site owner's legal exposure, not the vendor's, whatever the sales deck said. Zero is reachable. It just needs an owner, a schedule, and a count that nobody is allowed to average away.
Related reading: Target Size Pass Rate: Catching Clickable Boxes Too Small to Use, Contrast Failure Rate by Template, Not by Page, Focus Visible Pass Rate: Measuring the Outline Shoppers Actually See.
Frequently asked questions
What is a keyboard trap?
A component a keyboard user can tab into but cannot leave using the keyboard alone, with no documented key that releases focus. WCAG 2.1 criterion 2.1.2 prohibits it at Level A.
Why track keyboard trap count if the target is zero?
Because counting assigns ownership. Traps usually arrive inside third party components and vendor updates, so a dated, recurring count per component is what gets them fixed and keeps them from quietly returning.
Can automated tools find keyboard traps?
Partially. Scanners catch some traps in simple components, but iframe embeds and interaction dependent traps need a manual keyboard walk of every template, modal, and widget.
Who is responsible for a trap inside a third party widget?
The site owner carries the accessibility exposure for components they embed. Vendor configuration fixes most traps; an unfixable one belongs in the procurement and renewal conversation.