Keyboard trap incidents: the accessibility metric that should always read zero

A missing alt text degrades a page. A keyboard trap deletes it. A keyboard only user, which includes many motor impaired users and screen reader users, who tabs into a trapped modal, video player, or embedded widget has one remedy: reload the page and lose their progress, or abandon the task. Metrics programmes that fold traps into a weighted score can report an improving dashboard in the same month a trap shipped in the checkout. The count has to sit outside the score, in red, until it is zero.

Level A placement matters for triage too. Traps fail the minimum tier of WCAG, the tier every procurement standard and settlement references first. If your programme fixes AA polish while an A level trap sits in a core flow, the priority order is upside down, and the metric layout is what allowed that to happen.

Why this one does not average

An incident is one confirmed trap in one component on one template or page type, verified manually with a keyboard, not a scanner suspicion. Automated tools are poor at traps because detecting one requires attempting to leave, so scanners mostly miss them and occasionally guess. Log scanner flags as candidates, promote them to incidents only after a tester has reproduced the trap with Tab and Shift Tab and the usual exit keys, and record the component: it is components, reused across fifty pages, that explain nearly every trap.

That component framing also gives the fix its leverage. One patched modal component clears the incident on every page that uses it, which is why the incident count should name the component rather than the URL. Track pages affected as a secondary number for impact, but fix and count at the component level.

How to count an incident

Add a keyboard only pass over your top task flows, cart, checkout, account, the main form, to every release that touches a shared component, and a monthly pass over the full template set. It takes a tester minutes per flow. Traps are almost always regressions introduced by a new widget or an updated player, so release gating, not annual auditing, is what holds the count at zero between audits.

The standing test that keeps it at zero

Keep reading: Focus Visible Failure Rate: The Metric That Predicts Keyboard Complaints, Alt Text Coverage vs Alt Text Quality: Two Metrics, Two Different Lies.

Frequently asked questions

What counts as a keyboard trap?

Any component that keyboard focus can enter but cannot leave using standard keys alone, so the user must reload or use a mouse to escape. WCAG 2.1 covers it at Level A in the no keyboard trap criterion, 2.1.2, which makes it a minimum tier failure.

Can automated scanning find keyboard traps?

Poorly. A trap is defined by behaviour over a sequence of keystrokes, so scanners mostly miss real traps and flag some harmless components. Treat scanner output as candidates and confirm every incident manually with a keyboard before it enters the count.

Why track traps as a count instead of a rate?

Because one trap in a core flow is a total blocker for keyboard users, and a rate or blended score can improve while that trap exists. A raw count with a zero target, naming the component responsible, keeps the severity visible until it is fixed.

Where do keyboard traps usually come from?

Shared components: modals, video and media players, chat widgets, embedded third party tools, and custom dropdowns. That is also the good news. Fixing the component usually clears the trap on every page that uses it at once.