The Date Picker That Eats Your Keyboard: Testing Traps at Checkout
WCAG 2.2 criterion 2.1.2, No Keyboard Trap, is one of the oldest rules in the standard, and date pickers on delivery and booking forms still fail it constantly.
A shopper tabs into a delivery date picker at checkout. The calendar opens, she picks a date with the arrow keys, and then she cannot leave. Tab does nothing, Shift Tab does nothing, and the only way out is to close the browser tab and start the order again. That is a keyboard trap, and it fails WCAG 2.2 Success Criterion 2.1.2, No Keyboard Trap, a Level A rule that has existed since WCAG 2.0.
Date pickers are the most common trap on storefronts because they are the most complex widget most stores ship. They combine a text input, a popup grid, and navigation controls, and each piece has to handle focus correctly or the whole thing becomes a dead end.
What 2.1.2 requires
The rule is short: if keyboard focus can be moved into a component, it has to be possible to move focus out of it with standard keyboard commands. The classic example is a plugin that traps focus until the user presses a specific key, but the rule covers any component where Tab stops working, including a date picker that swallows Tab to move between days.
The escape hatch matters. A modal dialog that traps focus is fine, because Escape closes it and focus returns to where it came from. A date picker that traps focus with no documented exit, and no Escape handling, is not fine, because the shopper has no way to know the exit exists.
How date pickers trap focus
The usual trap is a calendar grid that captures Tab to move between days, so Tab never reaches the close button or the next field. The fix is to use arrow keys for day navigation, which is the standard pattern, and leave Tab for moving in and out of the widget. A picker that uses Tab for days has confused two jobs.
The second trap is the picker that opens on focus and never closes. The shopper tabs into the date field, the calendar opens, and there is no way to close it without picking a date, even when she only wanted to skip past the field. Escape must close the picker and return focus to the input, and picking a date should close it too.
A test that takes five minutes
Tab into the date field, open the picker, and move through the days with the arrow keys. Press Tab and confirm focus leaves the picker to the next field. Press Escape and confirm the picker closes with focus back on the input. Then pick a date, confirm the input shows it, and tab onward without touching the mouse.
Run the same test on the booking and appointment forms, not just checkout. Stores often use a different picker on the service pages, and the trap that is fixed at checkout is still live on the booking form, where the same shopper will hit it next.
Related reading: Guarding Against the Instant Compliance Pitch, Captions on Product Videos: The Barrier Hiding in the Demo Reel, Accessible Store Locators and Pickup Selection: Maps Are Not the Only Way In.
Frequently asked questions
What is a keyboard trap?
A component that keyboard focus can enter but cannot leave using standard keys. WCAG 2.2 criterion 2.1.2 forbids it at Level A. A date picker that swallows Tab to move between days is the most common example on storefronts.
Why do date pickers trap focus?
Usually because the picker captures Tab to move between days, so Tab never reaches the close button or the next field. Arrow keys should move between days, and Tab should move in and out of the widget.
Is a modal dialog a keyboard trap?
No, when it is done correctly. A modal is allowed to hold focus, because Escape closes it and focus returns to where it came from. A date picker with no documented exit and no Escape handling is a trap, not a modal.
How do I test a date picker for traps?
Tab in, move with arrow keys, press Tab to confirm focus leaves to the next field, and press Escape to confirm the picker closes with focus back on the input. Pick a date and confirm you can tab onward without a mouse.