Skip to content
wcagc
←Back to blog
EAAtransportEN 301 549accessibility-statement

EAA compliance for travel and transport booking

How EAA compliance applies to travel and transport booking sites: what is in scope, what is required, and how to check it.

P

Pavel Charkasau

EAA travel booking compliance means the digital side of a passenger transport service has to be usable by people with disabilities, because the European Accessibility Act (Directive (EU) 2019/882) names passenger transport as a covered service and has applied since 28 June 2025. The law is precise about what it covers. Article 2(2)(c) lists the specific elements of air, bus, rail and waterborne transport that are in scope: websites, mobile apps, electronic tickets and electronic ticketing services, and the delivery of transport service information, including real-time travel information. So the parts you have to get right are the booking flow, the app, the e-ticket, and the timetable and disruption information you publish. For the web, the working technical bar is EN 301 549 and WCAG 2.1 Level AA. On top of that, a transport provider has to publish information about the accessibility of the service and keep an accessible way for travellers to report problems. One nuance saves a lot of confusion: urban, suburban and regional services get a lighter obligation, and physical assistance at the station sits under separate passenger-rights law, not the EAA. This guide is the practical version.

Does the EAA cover travel and transport booking sites?

Yes, if you sell passenger transport to consumers in the EU. Passenger transport is one of the services the European Accessibility Act covers, and the European Commission lists "services related to air, bus, rail and waterborne passenger transport" among them (European Commission). Scope follows the market, not the company's address, so an airline, ferry operator, coach line, or online travel agency selling into the EU is included for those sales.

The one exemption worth checking is size. A microenterprise that provides a service is not bound by the EAA's accessibility requirements. That means fewer than 10 people and an annual turnover or balance sheet total of no more than €2 million (Directive (EU) 2019/882, Article 3(23)). Most carriers and booking platforms are well past that line. A small independent tour operator might sit under it, though the accessibility work still widens who can book with you. We cover eligibility in more depth on our EAA overview.

Which parts of a transport service are actually in scope?

This is where transport differs from most EAA verticals: the law names the exact elements rather than the whole service. Article 2(2)(c) covers "the following elements of air, bus, rail and waterborne passenger transport services":

  • (i) websites — your booking site and any account or manage-my-trip area.
  • (ii) mobile device-based services including mobile applications — the travel app people book and check in with.
  • (iii) electronic tickets and electronic ticketing services — the e-ticket itself and the flow that issues it.
  • (iv) delivery of transport service information, including real-time travel information — timetables, disruption notices, connections. For information screens, this is limited to interactive screens located within the EU.
  • (v) interactive self-service terminals located within the territory of the Union — ticket machines and check-in kiosks, except ones built into vehicles, aircraft, ships or rolling stock.

Read that list the other way and it tells you what the EAA does not reach here. The physical journey, staff assistance at the gate, and the accessibility of the vehicle itself are governed by the EU's passenger-rights rules, not this directive. The EAA is about the digital layer a traveller touches to plan, book, pay, and get information (Directive (EU) 2019/882, Article 2(2)(c)).

What does the EAA require a booking site to do?

The directive is written in outcomes and points to a standard for the detail. Under Annex I, Section III sets the general bar for every service: information has to reach people through more than one sensory channel and in an understandable form, and "websites, including the related online applications, and mobile device-based services" have to be perceivable, operable, understandable and robust (Directive (EU) 2019/882, Annex I). Those four words are WCAG's four principles, which is not a coincidence.

For the technical specifics, the EAA relies on a harmonised standard. Meeting it earns a presumption of conformity with the law under Article 15, and for anything web-facing that standard is EN 301 549, which points to WCAG 2.1 Level AA (EN 301 549). So the practical target for a booking site is WCAG 2.1 AA across the whole path a traveller takes: search, results, seat or fare selection, passenger details, payment, and the e-ticket.

Transport also carries duties that WCAG never mentions. Annex I, Section IV(c) requires the provider to supply "information on the accessibility of vehicles, the surrounding infrastructure and the built environment and on assistance for persons with disabilities", and information "about smart ticketing... real-time travel information (timetables, information about traffic disruptions, connecting services...) and additional service information" (Directive (EU) 2019/882, Annex I). In plain terms: a screen-reader user has to be able to find out whether a train has a wheelchair space, and read a delay notice, not just buy the ticket.

What about urban, suburban, and regional transport?

They get a narrower obligation. For urban, suburban and regional services, only the self-service terminals are in scope — the websites, apps, and e-ticketing elements are carved out (Directive (EU) 2019/882, Article 2(2)(c)). A city metro's ticket machine has to meet the terminal requirements in Section I of Annex I; its app does not fall under the EAA on the same footing as a national rail operator's.

The line between "regional" and "long-distance" is set in national law as each Member State transposes the directive, so if your network straddles both, check the local implementation rather than guessing. And the carve-out is specific to those short-haul modes. An intercity rail booking site or an airline app has no such relief.

The travel and transport booking checklist

Work through this in the order a traveller does. It maps the WCAG 2.1 AA bar onto the parts of a transport service that tend to break, then adds the transport-specific and administrative duties.

The booking journey (WCAG 2.1 AA across every step):

  • Search and results: origin, destination, and date fields are real, labelled form controls a keyboard can reach; results are announced, and fares and times are conveyed in text, not colour or position alone.
  • Fare and seat selection: seat maps and fare tables are operable without a mouse; the selected seat and price are announced, not just highlighted.
  • Passenger details: labels stay visible, errors say what went wrong and how to fix it, and fields for accessibility needs (wheelchair space, assistance request) are reachable and clearly named.
  • Payment: the whole flow works with a keyboard and a screen reader, error messages are tied to the right field, and any time limit on holding a fare can be extended.
  • The e-ticket: the ticket a traveller receives (QR code, barcode, or wallet pass) comes with a text alternative a screen reader can read, and the confirmation email is structured, not an image.

Transport-specific information (Annex I, Section IV(c)):

  • Publish accessibility information about the service (step-free access, wheelchair spaces, assistance booking) in text a screen reader can read.
  • Make real-time information accessible: timetables, disruption and delay notices, and connection details, not only in a visual live board.

Administrative:

  • Publish the accessibility information the EAA requires (see below) and give travellers an accessible channel to report a barrier.

Do you still need an accessibility statement?

Yes. Article 13 requires a service provider to "prepare the necessary information in accordance with Annex V" explaining how the service meets the accessibility requirements, and to make it available to the public in written and oral format, including in a form accessible to people with disabilities (Directive (EU) 2019/882, Article 13). This is the EAA's version of an accessibility statement, and it is one of the gaps regulators notice first.

A useful statement names the standard you work to (EN 301 549 / WCAG 2.1 AA), records your current conformance honestly, lists known limitations with a timeline for fixes, and gives a contact for reporting problems. EN 301 549 Annex C is a clause-by-clause template you can mark met, partially met, or not met, which is the natural backbone. If you want a starting draft, our accessibility statement generator builds one from your scan results that you then review and finish. And a plain caution: a statement documents your effort, it does not by itself make the service conformant. The work behind it does.

Here is the founder opinion I will stand behind. The useful question is not "will they enforce it" but "what would an auditor see on my booking flow today" — and for a transport site that means testing the seat picker and the payment step with a keyboard, because that is exactly where these journeys fall apart. Our scanner will flag the machine-detectable problems there; it will not tell you whether the seat map is genuinely operable end to end. That last mile needs a person with a screen reader. Claiming a tool alone makes a site conformant is what earned the overlay vendor accessiBe a $1 million order from the US Federal Trade Commission for representing that its product made websites WCAG compliant (FTC). Automation finds issues; a person confirms conformance.

Frequently asked questions

Does the EAA apply to my travel booking website?

Most likely, if you sell passenger transport to consumers in the EU. The EAA covers the websites, apps, e-ticketing and travel information of air, bus, rail and waterborne services, and scope follows the market, so operators outside the EU selling into it are included. The main exception is a microenterprise providing a service.

What standard does a transport booking site have to meet?

For the web, WCAG 2.1 Level AA, because that is the bar built into EN 301 549, the harmonised standard the EAA relies on. Meeting the relevant EN 301 549 clauses gives a presumption of conformity with the law under Article 15.

Are urban and regional transport services exempt?

Partly. For urban, suburban and regional transport, only self-service terminals are in scope under Article 2(2)(c); the websites, apps and e-ticketing elements are carved out. Long-distance and intercity air, bus, rail and waterborne services have the full obligation.

Does the EAA cover physical assistance at the station?

No. The EAA covers the digital elements — the booking site, app, e-ticket, and travel information. Physical assistance and the accessibility of vehicles are governed by the EU's separate passenger-rights rules, not this directive.

Can an automated scanner prove my booking site is compliant?

No. Automated tools catch roughly 30–57% of issues, mostly the machine-detectable ones (Deque). Confirming that the seat map, payment step and e-ticket work needs manual testing with a keyboard and a screen reader.

Check your booking flow against the standard

The practical first move is to measure the templates that carry a booking (search, results, seat selection, payment, and the confirmation) against WCAG 2.1 AA, since that is the bar EN 301 549 sets for the web. Run a free scan to surface the machine-detectable issues, then work through the manual checks a scanner cannot judge. You will have a real baseline and the evidence to write an honest accessibility statement instead of a guess.

Pavel Charkasau, founder, wcagc.com. Last updated 24 August 2026.

Sources