How the keyboard-operability check works
This explains, without technical detail, what the keyboard check does when a hotel booking form is reviewed, what it looks at, what it decides, and where it deliberately stops.
What it does and why
Some people cannot use a mouse. They move through a page with the Tab key and act on things with Enter, Space, or the arrow keys. Accessibility rules require that anything you can do with a mouse must also be doable with a keyboard alone.
This check answers one question for a hotel booking form:
If you only had a keyboard, could you actually complete a booking?
It focuses on the three boxes every booking form has:
- Destination ("Where do you want to go?")
- Dates (the calendar)
- Guests & Rooms (adults, children, rooms)
For each one it opens the box and tries to use the things inside it — day squares, plus and minus buttons, destination suggestions, Apply/Accept buttons — using nothing but the keyboard.
There are really two separate keyboard questions, and this check only owns the second one:
| Question | Who answers it |
|---|---|
| Can I even get to this control with the Tab key? | The keyboard navigation check (a different report) |
| Once I'm on it, does pressing Enter/Space/arrows actually do anything? | This check |
What it takes into account
1. Whether the thing is actually a control
The check only tests things it can recognise as controls: real buttons, links, form fields, and custom elements that the site has properly labelled as behaving like a button, a checkbox, a slider, a dropdown, and so on.
For each kind of control there is a known "correct key". A button should react to Enter or Space. A checkbox to Space. A slider to the left/right arrows. A calendar day to Enter. If the check does not know what key a thing is supposed to respond to, it does not invent one and does not report it — it leaves it alone.
Inside booking widgets specifically, it can also recognise some booking-specific shapes even when the site has not labelled them properly — a day square in a calendar, a plus/minus counter, a suggestion row, a next/previous month arrow.
2. Whether the control is currently visible and present
Things that have disappeared from the screen (because the popup closed, or because a filter hid them) are not judged directly. Where a hidden row is clearly one of a family of identical rows that was judged, it is attached to that existing finding as an additional occurrence rather than treated as a separate problem.
3. What "something happened" means
After pressing a key, the check looks for any real sign of a reaction: a panel opening or closing, an option becoming selected, a number going up, a dialog appearing, the page trying to move to another screen.
Deliberately, the page merely scrolling does not count as a reaction — that just means the browser moved the view, not that the control did anything.
4. The control that opens the box, not just what's inside it
If you can reach the "Guests" box with Tab but pressing Enter, Space, or an arrow never opens it, that is itself reported — because everything inside becomes unreachable. Before reporting it, the check retries with the other reasonable keys, so a box that opens on Space rather than Enter is not blamed.
5. Whether the widget works as a whole
Some booking forms are built so you step through options with the arrow keys rather than acting on each row individually. When the check confirms the whole widget can be driven that way end to end, it withdraws the individual row-by-row complaints — the site's approach works, even if each row would look odd in isolation.
What it checks, step by step
For every control inside an open booking box:
- Put the keyboard focus on it.
- Press the keys that control is supposed to respond to. A button gets Enter and Space; a calendar day gets Enter; a counter gets the arrows. Only one of the expected keys needs to work — a button that responds to Space but not Enter is fine.
- Watch for a reaction using the signals above.
- If nothing happened, click it with the mouse and watch again.
- Compare the two results.
The decision comes out like this:
| Keyboard | Mouse | Result |
|---|---|---|
| Something happened | — | ✅ Fine, nothing reported |
| Nothing happened | Something happened | ❌ Reported — this is the real accessibility failure |
| Nothing happened | Nothing happened either | ⬜ Not reported — it isn't really a control |
| Only the page scrolled, both ways | — | ⬜ Not reported — no actual action exists |
- Put things back the way they were before moving to the next control, so one test does not spoil the next.
Repeated identical rows — for example, twenty hotel rows in a destination list that all behave the same way — are grouped: one main finding plus a list of the other places it happens, instead of twenty separate complaints.
Restrictions and limitations
Things it will not report
- Things nobody can use. If neither keyboard nor mouse does anything, it is treated as decoration, not a broken control. A genuinely dead control therefore will not appear here.
- Controls you cannot even reach with Tab. That is a navigation problem and belongs in the other report. Reporting it here as well would double-count the same underlying issue.
- Text boxes you can type into. A destination field you can type into is already keyboard-usable — pressing Enter on it doing nothing is not a failure. (A date field you cannot type into, used only to open a calendar, is still tested.)
- Ordinary links with a real web address. Following a link with Enter is standard browser behaviour.
- Submit buttons, where submitting the form is exactly what is supposed to happen.
- Standard operating-system dropdowns, which the browser already makes keyboard-usable.
- Already-selected tabs, decorative images, and carousel slides, which are not controls users act on.
- Controls inside a box that never actually appears on screen. Only the control that should have opened it is judged.
Things it cannot see
- Controls with no clues that they are controls. A calendar day built as a plain piece of page text, with nothing marking it as clickable, is invisible to the general rules. Inside booking widgets some of these are now recognised by shape, but coverage is not complete.
- Content tucked inside certain isolated page components is skipped rather than risk a wrong answer.
Practical limits
- Long lists are sampled, not exhausted. After roughly ten controls of the same kind, and up to about a hundred options in one list, the check stops probing more of the same — otherwise a page with five hundred hotels would take far too long.
- A limited number of moves per box. The walk through each open box stops after a set number of key presses.
- Sites that behave differently each visit. A few booking sites do not reliably display their suggestion lists, so results on those sites can vary between runs, by browser session or by region.
- Sites that block automated visits or time out cannot be measured at all.
- A known grey area: some controls do react to the keyboard, but with the wrong action — for example running a search instead of opening the calendar. For now these are reported under the same keyboard rule, pending a more precise category.
A few concrete examples
- A
+button for adults that only responds to a mouse press → you can Tab to it, Enter and Space do nothing, clicking adds a guest. Reported. - A calendar day that ignores Enter but selects when clicked. Reported.
- A "Guests" box you can Tab to, but no key opens it, while clicking does. Reported, because everything inside is out of reach.
- A Confirm button that reacts to Space but not Enter. Not reported — one working key is enough.
- A decorative banner image inside the popup that does nothing when clicked or pressed. Not reported.
- A destination field you can type into, whose suggestions also appear on click. Not reported — typing is a keyboard interaction.
- A date field you cannot reach with Tab at all. Not reported here — it appears in the keyboard navigation report instead.
Summary
The check only judges things it can recognise as controls and knows the right keys for. It presses those keys, then clicks with the mouse, and compares. If the mouse works and the keyboard does not, that is the failure it reports. If neither works, it is not a control. If you cannot even reach it with Tab, that belongs to the navigation report. Page scrolling never counts as the control doing something.