Keyboard traps in the booking row
What it does and why
Some people navigate a website entirely with the keyboard — no mouse. They move from one field or button to the next by pressing Tab, and go back by pressing Shift+Tab.
A keyboard trap happens when focus (the highlighted field the keyboard is "on") lands on something and then simply won't leave. The traveler can't reach the next field, can't go back to the previous one, and can't finish the booking. They're stuck.
This check exists to find exactly that situation on the main booking row — the fields a traveler tabs across before anything pops open:
| Control | |
|---|---|
| 📍 | Destination |
| 📅 | Dates / Calendar |
| 👥 | Guests & Rooms |
| 🔍 | Search / Book button |
How it checks, one control at a time
Instead of walking the whole form in one long pass, the tool tests each control on its own, like a careful tester repeating the same short experiment down the row:
- Clear the way. It presses Escape a couple of times, in case the previous control left a calendar or dropdown hanging open.
- Land on the control. It puts keyboard focus directly on the field being tested.
- Try to leave going forward. It presses Tab and watches where focus goes.
- Try to leave going backward. Only if Tab failed to get out, it returns to the control and presses Shift+Tab.
- Decide. If focus escaped in either direction, the control is fine and the tool moves on. If neither direction let focus out, that control is reported as a keyboard trap.
Each control is judged independently, so a stuck field early in the row doesn't hide problems in the fields after it — several traps in the same form can all be reported.
What it takes into account
- Both directions matter. One working exit is enough. A control you can leave with Shift+Tab, even if Tab keeps you in place, is not reported — that matches the official rule for this criterion.
- Multi-part fields get room to breathe. A single date field can contain several internal stops (month, then day, then year). Pressing Tab once might look like nothing happened, even though the traveler really did move forward inside the field. So the tool presses several times before deciding a control is stuck — a genuinely trapped control survives every press, a multi-part field doesn't.
- Leaving to the browser still counts as leaving. If Tab moves focus up to the browser's own toolbar or address bar, that's a valid escape — the traveler is out of the form and can carry on.
- Room to settle. After each press, the tool waits a moment so animated or slow-loading widgets have time to respond before it reads the result.
- The right form gets tested. If a page has more than one form that matches the booking area (say a search form and a newsletter sign-up), the tool picks the one with the most interactive fields — the one that actually looks like a booking row.
- When a trap is reported, the advice is tailored. The finding names the specific control and explains the likely cause based on what's actually on that field — for example, quoting a keyboard-blocking setting found on it, or pointing to focus being pushed back onto the field. If the field is a read-only date trigger, the report also notes that its calendar needs to be keyboard-friendly too.
What it verifies
For each control in the booking row, it confirms one simple thing:
Once keyboard focus is on this control, can it get away — either forward with Tab, or backward with Shift+Tab?
If the answer is no in both directions, the tool reports it under WCAG 2.1.2 – No Keyboard Trap, with the control's name, the steps to reproduce it, and a description of what the traveler experiences:
Title: Keyboard trap on a
Check-in datein the booking flow Actual Result: Focus becomes trapped on the control: once focus reaches it, neither Tab nor Shift+Tab moves focus away, so the traveler cannot continue through the rest of the form or return to previous controls using the keyboard.
What it does not cover
This check is intentionally narrow. It stays silent in all of these cases:
- Anything inside a pop-up panel. Once a calendar, destination list, or guest selector opens, whatever happens inside it is covered by a separate check. Only the outer row is judged here.
- Panels that open the moment you land on a control. If focusing a field immediately opens its panel and pulls focus inside, the normal tab order no longer applies. The tool leaves that case to the separate check rather than guessing.
- Loops between several controls. Focus bouncing endlessly between two or three fields (Destination → Dates → Destination → …) is not reported by this check. That scope was set aside during review; only a single control that pins focus is reported.
- Controls the keyboard can't even reach. A field that can't receive focus at all isn't a trap — it's a keyboard navigation problem, and a different check reports it.
- Pages with no identifiable booking area. If no booking form can be located, the tool reports nothing here rather than checking the whole page (which another test already does).
- Anything it can't verify cleanly. If the page rearranges itself mid-check, a field disappears, or something goes wrong while measuring, that control is quietly skipped. A trap is only ever reported on clear, repeatable evidence — the tool would rather miss one than raise a false alarm.
- Escape hatches other than Tab. If a control can only be left with Escape or arrow keys, the official rule says that's acceptable as long as the traveler is told about it. That nuance isn't judged here.
The check also leaves the page as it found it: the temporary marks it uses to keep track of which control it's testing are always removed when it's done.
In one sentence
The tool lands on each booking control in turn, presses Tab and then Shift+Tab, and reports a 2.1.2 keyboard-trap issue only when a control refuses to let focus go in either direction — skipping pop-up interiors, focus loops, unreachable fields, and anything it can't measure reliably.