Accessibility

What has been measured, what has not, and how to report a barrier

Report a barrier

Tell us the page and what happened. What you were using helps, and is not required. Use the contact form, topic “Accessibility”. A person reads it. We aim to reply within a few days.

Write to us about this

What has been measured

Colour contrast on this site's own colours has not yet been measured for this build, and no result is claimed here. An automated check of 20 design drawings of company pages, at two widths, on Sat 26 Sep 2026 reported no failures. An automated check finds only part of what can go wrong, and it ran on drawings, not on this site.

What has not been tested

Testing with assistive technology, by people who use it daily. A keyboard-only walk through every page. Zoom to 400 per cent, and text spacing overrides. Forced colours on a real high-contrast theme. Any independent audit, of any kind. None of these has been done, so nothing here is evidence that it passes.

What we build to

We aim for no text under 12 pixels. Measured on the live site: not yet. Text below 11px appears in places, and there are surfaces where the type is smaller than it should be for a screen read in bright terminal light. The ranked board does not yet carry list semantics, so a screen reader announces it as loose text rather than as a set of options. Focus styling is inconsistent across components. Every one of these is a defect with a queue row, not a design decision.

What already works

The airport picker is a full keyboard combobox with proper listbox semantics. Reduced-motion preferences are respected throughout. Absence is stated in words rather than shown only as an empty space, so a missing number reads as missing rather than as zero.

Enforced on every build

These hold on every file under app/ and kit/ that the linter covers, because the build fails otherwise: every image carries a text alternative; every button declares its type, so pressing it never submits a form by accident; anything that responds to a click also responds to a key; anything that responds to the pointer arriving also responds to focus; every form label is bound to a control; every link leads somewhere rather than standing in for a button; a native element is used wherever one exists, rather than a div given its role; ARIA attributes appear only on roles that support them; no static element is relabelled as a control; no static element carries a handler without a role. Each sentence is tied to the linter rule that enforces it, and a rule removed from the linter removes the sentence here on the same build.

The standard, and travel access

WCAG 2.2 at level AA is the target. A target is not a conformance claim. No independent audit has been carried out. We will add routes with no steps for each airport we cover. Until then our return-buffer estimate assumes a traveller who can walk the route it describes, and it is not correct for every traveller. Do not rely on our timings if you need assistance; add your airline's own assistance window on top.

Accessibility statement

Being written. Not lawyer reviewed. This text will cover: the wording of a conformance statement, in each market that requires one; the enforcement procedure, and the body a reader can go to; when the statement was prepared, and how.

Changes to this page

Sat 26 Sep 2026. The statement itself is still being written.

Draft. Not lawyer reviewed. Last updated Sat 26 Sep 2026. A record, not a certificate. No independent audit has been carried out. It has not been through a formal accessibility audit and there is no VPAT; when there is, that will be said here rather than implied.