Hospitality Booking
A specialised set of checks for hotel booking flows — the destination field, the calendar, and the guests-and-rooms panel.
Why it exists separately
A booking form hides almost everything that matters. The destination list only appears once you click the destination field; the calendar only appears once you click a date; the guests panel only appears once you open it. A conventional automated scan reads the page as it first loads, so it never sees any of that content — and that content is most of what a traveller actually has to operate.
These checks open each widget the way a visitor would, and then run the accessibility checkpoints inside the open panel.
What is checked
| Page | What it covers |
|---|---|
| Widgets covered | Which widgets are recognised, how they are found, and how completely each type is supported |
| Keyboard navigation | Whether a keyboard user can reach and choose the options inside a widget |
| Keyboard operability | Whether pressing Enter, Space or the arrow keys on a control actually does something |
| Keyboard traps — booking row | Whether focus can get stuck on a control in the main booking row |
| Keyboard traps — inside panels | Whether focus can get stuck once a destination list, calendar or guests panel is open |
| Colour contrast | Whether the text and graphics inside an open panel are readable |
What to expect from the results
Each page below ends with a limitations section, and those are worth reading before reviewing a run. Two points apply across all of them:
- Some sites cannot be checked at all. Many travel sites show a security screen to anything that does not look like a human visitor. The run finishes cleanly and produces a screenshot, but nothing is reported — which is not the same as "no problems found". In recent review rounds this affected roughly one site in four.
- Results can vary between runs on dynamic sites. Advertising pop-ups, cookie notices and forms that rebuild themselves mid-check can change the outcome on the same URL.