Keyboard navigation in booking widgets
This check answers one question for each booking widget: can a keyboard user actually reach and choose the options inside it?
Destination widget
What it can do now
- Find real barriers. When a booking site shows you a list of destinations but you can't actually reach or choose them with the keyboard alone, the tool now spots that and reports it. Cases that were being missed early on — lists that only appear after you start typing, lists that appear as soon as the field is focused, and lists where the focus never moves into the popup — are now all covered.
- Stop crying wolf. The biggest area of work was accuracy. Many sites were being flagged even though their destination options were perfectly usable by keyboard. Round after round these false alarms were tracked down and removed, including several well-known travel and hotel sites.
- Tell a real control from ordinary text. The tool no longer trusts how something is labelled behind the scenes. It looks for the signs a person would use — does the pointer change to a hand, does it light up when you hover, does anything actually happen — and only then asks whether a keyboard user can get to it.
- Report more clearly. Findings for the same widget are now grouped into one issue with all the affected items listed together, instead of being scattered across several separate reports, and the wording of the reports was tidied up.
- Behave the same way twice. Results became far more stable run-to-run. A dedicated consistency check (five runs per site) was introduced, and most sites now give identical results every time.
Where it stands
Measured accuracy for the destination widget reached about 92% in late July and kept improving through August and early September. By the last review rounds, the great majority of test sites either reported the correct problems or correctly reported nothing at all, and no backward steps were observed.
Pending / next steps: a small number of sites still need attention — one major booking site whose page has a special structure that will be handled on its own, plus a handful of sites the tool simply cannot load because they block automated visitors. Both are being tracked separately from this work.
Known limitations
These are the things the checker is honestly not able to do today. They're worth knowing when reviewing its results.
It doesn't try things out — it reads the signs. The tool never clicks the destination options it is inspecting. Clicking would select a destination, close the list and destroy the very thing being examined, could trigger a real search or navigate away mid-check, and on lists of dozens of items would make the check far slower. So instead it judges "is this a genuine control?" from appearance and behaviour cues. That trade-off is deliberate, and it is the root of the next two points.
It can miss a control whose behaviour is invisible from the outside. On some sites the clickable behaviour is wired up in a way the tool can't see. If that item also has no hand pointer and no hover reaction, it can slip past unnoticed.
It can occasionally over-report. Decorative text that a designer happened to style with a hand pointer and a hover highlight can look like a real control. For lists that appear after you type, one of the checks is deliberately relaxed (some sites paint their hover effect in a way that can't be read), which slightly raises the chance of a false alarm there.
Identical-looking items get identical verdicts. If two things look the same on screen and are built the same way, but only one of them actually works, the tool cannot separate them. It will either flag both or flag neither — never just the one that works. When this happens you'll see one issue with one extra item listed, not a whole false report.
"Reachable but invisible" is not this check's job. Some sites let the keyboard move through destination options that are never shown on screen. Technically they are reachable, so this check passes them — but the person using the keyboard has no idea where they are. That's a different accessibility question ("where am I?") and is handled elsewhere.
Some sites can't be checked at all. A number of travel sites detect and block automated visitors, or never finish loading. In those cases the tool sees a blank or partly-loaded page and reports nothing — which is not the same as "no problems found". Roughly 8–20% of sites in recent review rounds fell into this category.
It depends on being pointed at the right part of the page. If the booking area is identified imprecisely — or if the site generates a different page structure on each visit — the check can wander outside the booking area and report things that don't belong to it.
Complex or slow-loading sites can be unreliable. Sites that rebuild their destination widget repeatedly, or that take a very long time to load, can produce different results on different runs or time out.
Guests and rooms widget
What the checker can now do
- Find unreachable controls inside the panel. It opens the Guests & Rooms panel and checks whether a keyboard user can actually reach what's inside — the plus/minus buttons for adults and children, room settings, dropdowns, and the Accept/Confirm buttons. Controls that a keyboard user can see but never reach are now reported.
- Report when the booking area can't be reached at all. On some sites, a keyboard user cannot get into the booking form in the first place. Instead of staying silent, the checker now raises a single clear report covering the whole booking area, with a practical explanation of how to fix it.
- Give clearer, more specific reports. Early on, reports could say something vague like "a dropdown inside a widget" on pages that had several. Reports now identify which control and which part of the booking form is affected, and use the correct wording for the control that opens the panel versus the panel itself.
- Report the right thing, and only the right thing. A large share of the work was removing false alarms — cases where the checker flagged a problem that wasn't really there. It no longer flags controls that never actually become visible to a visitor, panels that already work fine with a keyboard, or controls that fall outside what this particular check is meant to cover.
- Keep working on sites that block automated tools. Some sites show a security screen instead of the real page. Previously this made the booking review fail outright with no screenshot to look at. It now behaves like every other check: it finishes, shows the screenshot, and reports no findings, so reviewers can immediately see what happened.
- Handle harder, more dynamic pages. Sites where the booking form moves, changes shape, or loads late as you interact with it are now handled far more reliably.
How much it was tested
Testing grew steadily from 3 sites in the first review round to 55 sites by the final round, across 13 review rounds plus a pre-production check. In the last full round, every usable site behaved as expected — no errors and no missed problems — which is why the feature was approved to move on to the pre-production stage. The follow-up pre-production spot-check confirmed the same behaviour, with no regressions in the Guests & Rooms panel.
Next steps
A small number of findings remain open and are being tracked as separate pieces of work, and one behaviour — focus landing on controls that are invisible to the visitor but still reachable by keyboard — still needs a decision on how it should be reported.
Known limitations
These are the situations where the check may not give a complete or reliable answer today.
Sites we cannot review
- Sites that block automated tools. Many travel sites show a "security check" screen to anything that doesn't look like a human visitor. In the largest sample (55 sites), about 1 in 4 could not be reviewed for this reason. The checker finishes cleanly and shows a screenshot, but there is nothing to report because the real page never loaded.
- Sites that load slowly or render blank. A few sites return an empty page or take too long, and have to be set aside rather than reviewed.
Things the check does not cover
- Panels that only open with a mouse. If the Guests & Rooms panel cannot be opened by keyboard at all, this particular check does not report what's inside it — that situation belongs to a different accessibility check ("can this control be operated by keyboard").
- Controls hidden from view but still reachable by keyboard. On some sites, keyboard focus moves into fields that are invisible on screen — the visitor cannot see where they are. The checker notices this internally, but it is not yet turned into a report; the team still needs to decide which accessibility rule it should be filed under.
- Content that only appears later. Controls that show up only after scrolling down or after several interactions are not part of the review, because the check looks at the booking form as it exists when the page is analysed.
- Grouped controls. On a few sites, a whole group of controls is treated as one focusable item and operated with arrow keys, rather than each plus/minus button being reachable on its own. Reporting for that pattern has not been defined.
Things that affect consistency
- The booking area has to be identified correctly. The review is aimed at a specific part of the page. On sites where that part shifts or is renamed as the page loads, an incorrect target can cause the wrong area to be reviewed, or the whole page to be reviewed instead.
- Pop-ups and consent banners. Advertising pop-ups, cookie notices and promotional modals can appear mid-review and change the outcome, so the same site may give slightly different results on different runs.
- Wording and suggested fixes vary. The explanation and recommended fix attached to a finding are generated per run, so their quality is not identical every time — the same site can get a very thorough suggestion one day and a thinner one the next.
- No controlled test page yet. There is still no purpose-built practice page that reproduces these patterns on demand, which makes a handful of rarer cases hard to reproduce and confirm consistently.