Keyboard traps inside booking panels
This is the companion to keyboard traps in the booking row. That check judges the row of fields you tab across before anything opens; this one judges what happens once a panel is open.
What this check does, and why
Some people cannot use a mouse. They move around a website using the keyboard: pressing Tab to step from one control to the next, Shift+Tab to step back, the arrow keys to move within a list or a calendar, Enter or Space to choose something, and Escape to close something.
For that to work, there has to be a way out of every part of the page. If the keyboard reaches a place it cannot leave, the person is stuck — they cannot go back, cannot go forward, and cannot finish what they came to do. They usually have no choice but to close the browser tab and start over. The accessibility rule that forbids this is WCAG 2.1.2 — No Keyboard Trap.
This check looks for exactly that problem inside the panels of a booking search form: the destination list that drops down, the calendar that opens when you click the dates, the "Guests & Rooms" panel with its plus and minus buttons, and the flight panel where there is one.
The purpose is simple: make sure that once someone opens one of those panels with the keyboard, they can still get out of it.
How it behaves, step by step
For each panel it finds, the tool does the same thing a careful person testing by hand would do:
- It makes sure the panel is really open and visible on screen. If the panel is not actually there, there is nothing to test.
- It puts the keyboard inside the panel, on the first control that can receive it.
- It presses Tab over and over, writing down which control the keyboard lands on each time. It keeps going until either the keyboard leaves the panel, the panel closes, or it notices the keyboard going round in circles.
- If the keyboard keeps coming back to the same single control, the tool becomes suspicious — but it does not report anything yet.
- It then tries every normal way out, one after the other:
- Escape (tried a few times — see below).
- Shift+Tab, to step backwards out of the panel.
- More Tab presses, to step forwards out of the panel.
- Choosing an option — pressing Enter or Space, and nudging the highlighted option with the arrow keys first, to see whether picking something closes the panel.
One working way out is enough. If any of those releases the keyboard, the panel passes and nothing is reported. The problem is reported only when every single one of them fails.
Afterwards, the tool re-opens the panel if its testing happened to close it, so the rest of the checks on that booking form carry on normally.
Why Escape is tried more than once: on some sites a small tooltip or helper bubble sits on top of the panel, and the first Escape only dismisses that bubble. A real person would simply press Escape again. So the tool does the same, instead of wrongly declaring a trap on a panel that can perfectly well be closed.
What it takes into account
Before it will even consider reporting, the tool checks several conditions:
- Is the panel genuinely open and visible? A panel that isn't really on screen is not tested.
- Can the keyboard get into the panel at all? If nothing inside the panel can receive the keyboard, that is a different problem — being unable to reach something — and it is already reported by another check. This one stays quiet so the same issue isn't reported twice.
- Can the button that opens the panel be reached by keyboard in the first place? If not, same reasoning: that is somebody else's finding, not this one's.
- Did the panel stay open throughout the test? If it vanished halfway through, the observation is unreliable and is thrown away rather than reported.
And these behaviours are all recognised as correct, so they are never reported:
| Situation | Why it's fine |
|---|---|
| The keyboard leaves the panel at any point during testing | There's a way out — that's the whole requirement |
| Escape closes the panel, or hands the keyboard back to the button that opened it | A standard, working exit |
| Shift+Tab or continued Tab moves the keyboard out | A standard, working exit |
| Picking an option closes the panel — choosing a destination, confirming a date | That is a successful exit, not a trap |
| An open dialog box deliberately holds the keyboard inside, but Escape works | This is the recommended way to build a dialog |
| The keyboard wraps around through the browser's own toolbar (address bar, etc.) | Normal browser behaviour, not the website's doing |
| The keyboard moves between two or more controls | A "loop", deliberately outside this check — see limitations |
What it reports when it does find something
A finding is raised only in one precise situation: the keyboard is stuck on one single control inside the panel, and none of the ways out work.
A concrete example: you Tab into a destination list, the keyboard lands on the search box, and from then on Tab does nothing, Shift+Tab does nothing, the arrow keys do nothing, Escape does nothing, and pressing Enter doesn't close the list either. You can see the list of cities on screen, but you can never reach any of them, and you can never get back to the rest of the form.
The report tells you:
- Which panel is affected — Destination, Calendar, Guests & Rooms, and so on.
- Which specific control the keyboard is stuck on, by its name, whenever that control can be identified — and it highlights it on the page so it's easy to find.
- How to reproduce it, step by step with the keyboard.
- What actually happens, described as what the person experiences: focus stays on that one control, so they cannot move to the panel's other options or make a selection.
Limitations — what it does not cover
- Only "stuck on one single control" is reported. If the keyboard bounces back and forth between several controls — for instance between the
+and−buttons of Guests & Rooms — that is a loop, and it is intentionally left out of this check. That decision was made during review and is tracked separately. - Only the inside of the panels. Problems on the surrounding page, or on the buttons that open the panels, belong to other checks — the booking row is covered by its own check.
- Only the standard ways out are tried — Escape, Tab, Shift+Tab, and picking an option. If a site uses some other unusual key to escape and never tells the user about it, the tool won't find it. (That's arguably a problem in itself: an exit nobody is told about isn't much of an exit.)
- Dropdown lists drawn by the operating system are skipped. When a site uses a plain browser dropdown, the list of options is drawn by the browser itself, outside the web page — there is nothing on the page that could trap the keyboard.
- There is a limit on how many keys it presses. Very large panels are tested up to a fixed budget. That budget covers going all the way round any realistic panel twice over, but it is not unlimited.
- When in doubt, it says nothing. If anything goes wrong mid-test — the page navigates away, the panel disappears, a timing hiccup — the tool reports nothing rather than risk a false alarm. This means a genuine problem can occasionally slip through. That trade-off was chosen on purpose: a wrong report costs more time than a missed one.
- It doesn't judge how good the navigation is. Whether the order of the controls makes sense, or whether the arrow keys behave the way you'd expect inside a calendar, are separate accessibility topics covered by other checks. This one answers a single yes/no question: can the keyboard get out?