Direct answer: before a UK airline, OTA, tour operator, hotel group or travel tech product lets an **AI assistant, chat agent or generative overlay sit on the primary booking / assistance UI**, you must already treat that surface as a **service to the public** under the Equality Act 2010. That means the duty to avoid discrimination and to make **anticipatory reasonable adjustments** for disabled people applies to the website and app path itself — including any AI layer that steers, summarises, books or closes the journey. WCAG AA is the practical benchmark for booking and check-in functions; an AI chat that only works for sighted mouse users, or that replaces the only Special Assistance path, is a product failure before it is a model-quality issue.
That is the operator question Kaize is answering here. We are a UK AI product studio for travel and hospitality. This is not a redesign checklist for every pixel. It is a **control-stack** article for AI on booking UIs: what must already be true before the model is allowed to **own** the journey rather than **assist** beside an accessible path. It sits beside — and does not replace — our CMA AI-agent consumer-law, ATOL AST 14 booking-assistant disclosure, UK261 disruption notifications, how travel companies should control AI agents and CRM/booking system-of-record pieces.
Primary evidence is first-party UK public sources: the EHRC statutory Equality Act 2010 Code of Practice for services, public functions and associations, 2026 (updated **5 August 2026**), which is explicit that Part 3 obligations apply to services provided on a website; the Equality Act 2010 itself (including the duty to make reasonable adjustments for disabled people); and the UK CAA Airline Accessibility Guidance, which strongly recommends that airline websites and apps — including homepage, passenger-rights information, essential disabled-passenger information, and the **booking and check-in function** — conform to the latest WCAG (at least AA). We do not invent client results, fine outcomes, GSC lifts or GEO ranks.
Why booking UI accessibility is an AI control problem now
Travel operators are adding AI into enquiry, itinerary, special-assistance and checkout flows. That is useful when the model drafts, explains or retrieves. It becomes unlawful-risk product design when the only workable path to book, amend, request assistance or understand an irreversible confirmation is an inaccessible AI surface — voice-only without captions, chat-only without keyboard parity, modal overlays that trap focus, or generated copy that replaces structured forms disabled travellers already rely on.
The 2026 Code is a statutory Code of Practice. Courts must take relevant parts into account. It does not invent a new website duty; it restates that Part 3 covers services to the public **on a website**, and that service providers should regularly review whether services are accessible to disabled people, act on access audits, train staff on adjustments, and review whether those adjustments still work. AI does not sit outside that frame because it is "new".
- Map every AI path that can become the **only** way to complete booking, payment, check-in, Special Assistance or passenger-rights information.
- Do not treat "we have a WCAG score on the old form" as enough if the AI overlay is now the default journey.
- Document equivalent channels (phone, structured form, assisted booking desk) **before** go-live — and make them one click discoverable, not a dead-end FAQ.
Gate 1 — Treat the AI surface as part of the service
Under Part 3, discrimination and the reasonable-adjustment duty attach to the service you provide to the public. If your product puts an AI assistant in front of booking or Special Assistance, that assistant is part of how the service is delivered. The Code’s good-practice steps for adjustments — review accessibility, audit, train, re-check effectiveness — apply to the combined UI, not only the static HTML shell.
- Inventory: primary booking path, amendment path, Special Assistance / PRM path, rights information, and any AI chat that can complete or block those steps.
- Classify each AI step as assist-beside vs own-the-journey. Ownership needs a higher control bar.
- If AI can refuse, close or soft-block a disabled traveller’s request, also run your ADM / consumer-law stacks separately — accessibility does not replace those duties.
Gate 2 — Keep WCAG-class booking and check-in paths workable without the model
The CAA’s Airline Accessibility Guidance expects websites and applications to conform to current WCAG and, at minimum, that homepage, passenger-rights information, essential information for disabled and less mobile passengers, and the **booking and check-in function** meet WCAG AA (guidance references WCAG 2.1 as the strong recommendation floor; use the latest WCAG your programme can evidence). It also expects Special Assistance information one click from the homepage, clear language, and design aligned with international accessibility guidelines.
For AI product teams the non-negotiable reading is: the model may accelerate the journey, but it must not be the only accessible journey. Keyboard operability, focus order, name/role/value for controls, error identification, confirmation of irreversible actions, and equivalents for captions/transcripts where voice is offered are product requirements — not "nice-to-have prompt engineering".
- Ship a structured, keyboard-operable booking / assistance path that works with screen readers **with AI disabled**.
- If you offer voice or multimodal AI, provide text equivalents and do not require a mouse-only hover to reach Special Assistance.
- Never bury Special Assistance behind an AI gate that fails closed for assistive tech.
Gate 3 — Anticipatory reasonable adjustments, not "tell us after it breaks"
The Equality Act’s reasonable-adjustment duty is anticipatory for service providers: you should think ahead about barriers disabled people are likely to face, not wait for each individual complaint. The 2026 Code emphasises regular review, access audit by a suitably qualified person, staff training relevant to the adjustments, and checking that adjustments still work. AI features change interaction patterns fast — so re-test after each material assistant release, not once a year.
- Include AI overlays in accessibility regression (keyboard, SR, zoom, reduced motion, timeout extensions).
- Keep human-assisted booking / Special Assistance phone or callback as a first-class channel with comparable outcomes.
- Log when AI cannot complete an assistance request and route to a trained human — do not loop the traveller in generated apologies.
Gate 4 — What the model must not invent or decide alone
Accessibility failures often look like "helpful" automation: the assistant invents SSR codes, invents wheelchair dimensions, promises a seat that inventory cannot guarantee, or tells a traveller their only option is to continue in chat. Those are operational and legal risks. Put hard boundaries around assistance data, inventory truth and irreversible confirmations.
- Assistance needs and SSR / free-text requirements come from structured capture + human confirmation for material commitments — not free-form model invention.
- AI may **draft** explanations of rights and assistance options from approved content; it must not silently replace CAA/operator-approved rights copy with paraphrases that omit choices.
- Irreversible booking, payment or assistance-commitment steps require explicit, accessible confirmation controls outside a single ambiguous chat turn.
Gate 5 — Prove equivalent outcomes before scale
Before you make the AI path default, prove that a disabled traveller using assistive technology can achieve the same booking and assistance outcomes as a mouse-and-sight user on the non-AI path — and that the AI path does not introduce new barriers (focus traps, disappearing controls, time-outs, colour-only status, inaccessible CAPTCHA in front of the assistant).
- Acceptance tests: complete book / request assistance / read rights with keyboard + screen reader on both paths.
- Compare time-to-complete and error recovery; if AI path is worse for assistive tech, do not make it default.
- Publish an internal accessibility statement for the AI surface owners: what was tested, when, against which WCAG version, and what is still open.
How this fits the Kaize control stack
Accessibility on AI booking UIs is adjacent to, not a substitute for, consumer-law agent behaviour, ATOL assistant disclosure, passenger-rights notifications and agent access control. A model that is polite in chat can still discriminate in effect if the only channel fails for disabled travellers. Build the Equality Act / WCAG controls into the same release gate as SSR truth and confirmation UX.
Kaize designs and builds travel products where AI assists operators without quietly becoming the inaccessible front door. If you are putting an assistant on booking or Special Assistance, start with the five gates above — service mapping, WCAG-class non-AI path, anticipatory adjustments, no invented assistance commitments, and evidenced equivalent outcomes — then wire measurement and human fallback before traffic.
Sources
- Equality Act 2010 Code of Practice for services, public functions and associations, 2026 (GOV.UK / EHRC) — updated 5 August 2026; websites as services; reasonable adjustments practice.
- Equality Act 2010 — Part 3 services; disability reasonable adjustments.
- CAA Airline Accessibility Guidance (PDF) — WCAG for airline websites/apps; booking and check-in; Special Assistance information one click from homepage.
- Related Kaize journal: CMA AI agents / consumer law, ATOL AST 14 disclosure, UK261 AI notifications, AI agent access control.