EAA Travel and Hospitality Compliance: Booking Flows, Forms, and Conformance

The EAA covers passenger transport services and consumer-facing e-commerce among its categories, and travel sits across both. In practice, the in-scope surface for a travel or hospitality business includes the websites, mobile apps, and self-service terminals that consumers use to research, book, pay for, and manage a trip.

• Air, rail, bus, coach, and waterborne passenger transport booking and ticketing, including seat selection and check-in flows
• Hotel, hostel, and short-stay accommodation booking engines and confirmation or management pages
• Online travel agencies, aggregators, and metasearch that complete a booking or payment
• Tour, activity, attraction, and event ticketing sold to consumers
• Account areas, e-tickets, boarding passes, booking-modification and refund flows, and the emails and PDF documents they generate

The Act focuses on consumer (B2C) services. One transport-specific nuance: urban, suburban, and regional transport services have narrower obligations than long-distance and international travel, and certain information duties are scoped more tightly. There is also a limited exemption for microenterprises that provide services, meaning fewer than 10 people and annual turnover or balance sheet not exceeding EUR 2 million. If you are larger than that, or you run a booking engine of any scale, assume you are in scope. For who must comply and how member states enforce it, see our overview of the European Accessibility Act.

A practical trap: white-labelled booking widgets, payment iframes, chat assistants, and date-picker libraries embedded from third parties are still your responsibility on your domain. Inventory every vendor component in the path to purchase, because the obligation covers the whole journey, not just the pages you built in-house.

The EAA is outcome-based, but conformance is shown through EN 301 549, the harmonised European standard, which references WCAG 2.2 Level A and AA as the baseline for web content. So the working target for your booking site and app is WCAG 2.2 A and AA.

WCAG 2.2 matters here because its newer success criteria hit booking flows directly. Watch these in particular:

• 2.5.8 Target Size (Minimum) (AA): seat maps, calendar date cells, and passenger-count steppers need targets of at least 24 by 24 CSS pixels, or adequate spacing
• 2.5.7 Dragging Movements (AA): map-based or slider room selection and price filters must offer a non-drag alternative such as buttons or inputs
• 3.3.8 Accessible Authentication (Minimum) (AA): login and booking retrieval must not force a cognitive test such as solving a puzzle or transcribing a code, with no easier path
• 3.3.7 Redundant Entry (A): do not make travellers re-key the lead passenger's details, dates, or address they already entered earlier in the same flow
• 2.4.11 Focus Not Obscured (Minimum) (AA): sticky fare bars and cookie banners must not hide the element a keyboard user has focused
• 3.2.6 Consistent Help (A): keep contact and help mechanisms in a consistent place across the funnel

WCAG 2.2 also removed the old 4.1.1 Parsing criterion, so do not spend audit time there. For colour, the contrast minimums still apply: 4.5:1 for normal text, and 3:1 for large text (at least 18pt, or 14pt bold) and for UI components and graphical objects such as form borders and the focus indicator.

A travel funnel is a multi-step transaction under time pressure, often with a held-inventory countdown. That combination is exactly where accessibility failures turn into abandoned bookings. Prioritise the spine of the journey: search, results, selection, passenger details, payment, and confirmation.

Keep every step keyboard- and screen-reader-operable

Every interactive element in the flow must be reachable and operable with the keyboard alone, in a logical order, with a visible focus indicator. Date pickers, seat maps, and room selectors are the usual offenders. When inventory updates the results list, announce the change to assistive technology with a polite live region so a screen-reader user knows prices or availability shifted.

Do not trap people in timeouts or steppers

Hold timers are common in ticketing. WCAG requires that users can turn off, adjust, or extend most time limits, so offer a clear way to extend the hold and warn before it expires. Quantity steppers (passengers, nights, rooms) need real, labelled buttons, not click-only widgets.

Make errors recoverable, not fatal

At payment, a declined card or an invalid date should produce a specific, text-based error tied to the field, not a colour change alone, and focus should move to the problem. Preserve everything the traveller already entered.

Passenger-details and payment forms are dense, with names, dates of birth, document numbers, loyalty IDs, and card data. Get these right and you clear most of the booking-flow risk.

• Give every input a programmatically associated label; placeholder text is not a label and disappears on entry
• Group related fields (outbound versus return, each passenger) with fieldset and legend so the relationship is announced
• Use autocomplete tokens (given-name, family-name, tel, cc-number) so browsers and assistive tech can fill known data; this also supports Redundant Entry
• Mark required fields in text, not by colour or an asterisk alone, and describe the expected format for dates and document numbers up front
• On error, summarise issues at the top with in-page links to each field, and repeat a specific message at the field itself
• Make the focus indicator on inputs and buttons meet the 3:1 contrast minimum so keyboard users can see where they are

Watch CAPTCHA and one-time-code steps at login and booking retrieval. Under 3.3.8, you must provide an authentication path that does not rely on recalling or transcribing a code with no alternative; allowing password managers and pasting OTPs is a simple way to comply. For the wider pattern, see our guide to accessible forms.

The EAA expects you to show your work, not just claim accessibility. Build an evidence trail you can hand to a market-surveillance authority or to a customer who asks.

• Run automated coverage first to catch machine-detectable issues across templates. A free pass with AccessScan gives you a ranked starting list for your booking and account pages
• Add manual testing for what tools cannot see: complete a real booking end-to-end with only a keyboard, then again with a screen reader (NVDA, VoiceOver, or TalkBack), including a deliberate payment error
• Document conformance against EN 301 549 and WCAG 2.2 AA, criterion by criterion, recording known gaps and remediation dates rather than overclaiming
• Publish an accessibility statement that names the standard, lists known limitations, and gives an accessible way to report problems and request help
• Make e-tickets, itineraries, and invoices accessible too, since tagged, readable PDF documents are part of the service

Treat this as ongoing. Fare engines, promotions, and seasonal templates change constantly, so add an accessibility check to your release process and re-test the booking spine after major changes. Work the highest-traffic conversion path first, then widen coverage. The payoff is concrete: a booking flow that works for a keyboard or screen-reader user is usually faster and clearer for everyone, which is good for conversion as well as compliance.