Passenger transport
Air, bus, rail and waterborne passenger transport. This covers websites, mobile apps, e-ticketing, live travel information and interactive self-service terminals.
This overview is informational, not legal advice. Whether a given product or service is in scope is a legal call for your organization to make.
What the EAA covers here
Passenger transport covers air, bus, coach, rail, and waterborne travel for consumers, across four surfaces named together: websites, mobile apps, electronic ticketing, and — where a transport operator provides them — interactive self-service terminals such as check-in and ticket-vending machines. Real-time travel information, timetables, and disruption updates fall inside the same scope, whichever surface delivers them.
Terminals used specifically for a transport service are reviewed under this sector rather than under the general self-service-terminals category, because the transport context brings its own constraints — journey timing, platform and gate information, accessibility assistance requests — that a generic terminal review wouldn’t capture.
Websites, apps, and terminals together
A single journey typically crosses several of these surfaces in sequence: search and booking on a website or app, an e-ticket delivered to a phone, and a check-in or boarding step that may happen at a kiosk rather than online at all. A review that only looks at the booking website and stops there misses the terminal step a passenger with a disability may depend on more heavily than most travellers do.
Real-time information
Delays, platform and gate changes, and disruption notices are time-sensitive in a way that raises the stakes of getting them wrong: a change announced only as a scrolling visual banner, or only as a station tannoy announcement, reaches only part of the travelling public. The same information needs a route to both a screen reader or visual display and an audible announcement, not just one of the two.
What auditors look at first
On the booking side, a review checks whether the purchase flow gives enough time to complete payment without an assistive-technology user being timed out, and whether seat, fare, and add-on selections expose their current state programmatically rather than only through colour or shading. On the terminal side, it checks whether every touchscreen action has a physical or audio-guided alternative, and whether real-time information — delays, gate changes — reaches both a visual display and an audible channel rather than defaulting to whichever one is cheaper to build. A last check usually covers assistance requests: whether a passenger can actually notify staff of an accessibility need through the same booking flow, rather than a separate phone-only process bolted on beside it.
What typically fails here
Recurring accessibility failures in this area. Illustrative — an audit reports what your own surfaces actually do.
- Ticket purchase flows that time out before a screen reader user can complete payment.
- Check-in kiosks that offer only touchscreen interaction with no alternative input.
- Real-time disruption and platform-change alerts posted only as a visual banner.
- Journey planner results with no structure connecting each leg to its time and platform.
- Seat and fare selection controls that don't expose their selected state to assistive technology.
EN 301 549 clauses this maps to
Clauses from our v3.2.1 report catalog — a curated subset of the standard, not the complete list of clauses that may apply to you.
- 9.1.3.1 Info and Relationships
- 9.2.1.1 Keyboard
- 9.4.1.2 Name, Role, Value
- 11.2.1.1 Keyboard (software)
- 11.2.5.1 Pointer Gestures (software)
- 5.1.5 Visual output for auditory information
- 4.2.7 Usage with limited manipulation or strength
Next: what a conformance report contains, or run the 2-minute readiness check.