Transport Accessibility Under the EAA: A Journey-Stage Compliance Guide for Operators and Travel-Tech Vendors
Transport is where the EAA gets complicated. Every other sector in scope - banking, e-commerce, e-books - is primarily a digital problem. Transport is a digital problem and a physical one, and the two layers are tightly coupled: a passenger who cannot use the booking app never reaches the gate; a passenger who cannot read the departure board cannot board the right train. The European Accessibility Act reaches into both layers, and it does so differently depending on which mode and which service type you operate.
This guide maps the EAA's transport scope stage by stage, identifies the failure modes that matter most, and gives compliance leads, product managers, and engineers a prioritised order of work.
Why transport is a hard case under the EAA
The EAA (Directive (EU) 2019/882) is a significant legislative measure aimed at improving accessibility for consumers with disabilities across the EU, and it identifies specific products and services within its scope - including travel, hospitality and leisure. Transport was not an afterthought: during preparatory work on the EAA a decade ago, passenger transport was identified as one of the priority sectors for reform.
The scope, however, is not uniform across service types. For air, bus, rail and waterborne passenger transport services (except urban, suburban and regional services), the EAA covers: websites; mobile device-based services; electronic tickets and ticketing services; delivery of transport service information including real-time travel information; and interactive self-service terminals located within the EU.
For urban, suburban and regional transport services, only interactive self-service terminals are in scope under the EAA's transport provisions. The rationale is stated in the Directive's recitals: since the EAA already contains obligations for the large majority of private transport service providers to make their websites accessible when selling tickets online, it is not necessary to introduce further requirements for the websites of urban, suburban and regional transport service providers.
In practice, this means a long-distance rail operator's booking website, app, e-tickets, real-time information and station kiosks are all in scope. A city metro operator's website and app are not in scope under the EAA's transport provisions - though they may be caught by other obligations, including the Web Accessibility Directive for public bodies.
The scope split is mode-agnostic, not mode-specific. An urban bus operator running a long-distance coach service on the same platform faces full EAA scope for the coach service. Operators running mixed fleets or mixed service types need to assess each service individually, not the company as a whole.
Journey-stage scope map: failure modes and fixes
The table below maps each digital journey stage to its EAA scope status, the most common failure modes, and the primary WCAG/EN 301 549 criteria at risk.
| Journey Stage | In Scope (long-distance) | Common Failure Modes | Key WCAG / EN 301 549 Criteria |
|---|---|---|---|
| Route/timetable search & fare selection | Yes — website & app | Inaccessible date pickers, interactive seat maps with no keyboard path, colour-only fare differentiation | 1.1.1 Non-text content, 1.3.1 Info & relationships, 2.1.1 Keyboard, 1.4.1 Use of colour |
| Passenger & assistance-request flows | Yes — website & app | Disability/assistance declaration buried in inaccessible modal, no confirmation of request receipt, CAPTCHA blocking form submission | 1.3.5 Identify input purpose, 3.3.1 Error identification, 3.3.8 Accessible authentication |
| Payment & checkout | Yes — website & app | Seat-hold timers expiring without warning, re-entry of passenger name already provided, inaccessible payment iframes | 2.2.1 Timing adjustable, 3.3.7 Redundant entry, 4.1.3 Status messages |
| E-ticket artefact | Yes — electronic tickets & ticketing services | QR/barcode-only ticket with no text alternative, untagged PDF boarding pass, wallet pass with no accessible label | 1.1.1 Non-text content, PDF/UA (EN 301 549 clause 10) |
| Online check-in & seat selection | Yes — website & app | Seat map rendered as image, no keyboard-accessible seat selection, mobile boarding pass inaccessible to screen readers | 1.1.1, 2.1.1 Keyboard, 4.1.2 Name/role/value |
| Real-time travel information & disruption alerts | Yes — transport service information incl. real-time | Platform change announced visually only, delay alert not exposed to assistive technology, push notification with no text equivalent | 1.3.3 Sensory characteristics, 4.1.3 Status messages, 1.4.1 Use of colour |
| Self-service terminals & station kiosks | Yes — all modes incl. urban/suburban/regional | See dedicated article | EN 301 549 clauses 5, 8 (hardware) |
Route/timetable search and fare selection
The booking funnel's first screen is frequently its most inaccessible. Date pickers built as custom JavaScript widgets often have no keyboard path and expose no accessible name to screen readers. Interactive seat maps - common in rail and air - are typically rendered as SVG or canvas with no text alternative and no keyboard-navigable equivalent.
Fare selection tables that use colour alone to distinguish fare classes fail WCAG 1.4.1. The fix is not to remove colour but to add a secondary differentiator: an icon, a text label, or a pattern. Seat maps need either a keyboard-accessible grid alternative or a list-based fallback that exposes the same information.
Passenger and assistance-request flows
This stage carries a specific legal weight beyond WCAG. The EU passenger-rights regulations - Reg. 1107/2006 (air), Reg. 2021/782 (rail, replacing 1371/2007), Reg. 181/2011 (bus and coach), and Reg. 1177/2010 (waterborne) - each impose obligations on operators to accept and act on assistance requests. The EAA's requirements sit alongside these passenger-rights obligations; the physical spaces used by clients of transport services may also be subject to accessibility requirements where a Member State implements the EAA's optional built-environment provisions. The two regimes are complementary, not alternatives: passenger-rights law governs what assistance must be provided; the EAA governs whether the digital channel through which a passenger requests that assistance is itself accessible.
A passenger who cannot complete an assistance-request form because it uses an inaccessible CAPTCHA is blocked at both layers simultaneously. WCAG 3.3.8 (Accessible Authentication, Level AA) requires that authentication steps - including bot-detection mechanisms - do not rely solely on a cognitive function test unless an alternative is provided.
Payment and checkout
Three WCAG 2.2 criteria bite hardest here.
SC 2.2.1 (Timing Adjustable) - Seat-hold timers are ubiquitous in airline and rail booking. A timer that expires without warning, or that cannot be extended, fails this criterion. The fix is a warning at least 20 seconds before expiry, with an option to extend.
SC 3.3.7 (Redundant Entry) - WCAG 3.3.7 is a Level A criterion introduced in WCAG 2.2 that requires information previously entered by the user in the same process not to be entered again, except where re-entry is essential for security or validation purposes. In a multi-passenger booking, asking a user to re-enter a lead passenger's name at the payment confirmation step is a clear failure. Pre-populate or allow selection from previously entered data.
SC 3.3.8 (Accessible Authentication) - Payment iframes from third-party processors frequently introduce inaccessible authentication steps. Operators cannot disclaim responsibility for third-party components embedded in their checkout flow; the obligation runs to the service as experienced by the user. See our accessible authentication guide for implementation detail.
The e-ticket artefact
The EAA explicitly names electronic tickets and ticketing services as in-scope elements for air, bus, rail and waterborne passenger transport. This means the ticket itself - not just the interface used to purchase it - must be accessible.
The most common failures:
- QR/barcode-only tickets with no human-readable text alternative. A screen-reader user cannot read a barcode. The ticket must include the journey details (origin, destination, date, time, seat) as accessible text alongside any machine-readable code.
- Untagged PDF tickets rendered as scanned images. These fail WCAG 1.1.1 and EN 301 549 clause 10 (non-web documents). A tagged PDF with a logical reading order, proper heading structure, and alt text for any logos is the minimum requirement. See our PDF accessibility guide for the full checklist.
- Wallet passes (Apple Wallet, Google Wallet) - these are governed by platform-specific accessibility APIs. Pass descriptions and field labels must be set correctly so VoiceOver and TalkBack can read them.
Online check-in and seat selection
Online check-in is a second booking funnel, and it inherits all the same failure modes. Seat maps reappear here, often in a different implementation from the original booking flow - meaning two separate components to fix.
Mobile boarding passes deserve specific attention. Screen-reader users report that activating the barcode on a mobile boarding pass is impossible without sighted assistance - digital boarding passes that purport to be accessible frequently are not. The barcode or QR code must have a text alternative containing the flight/journey details; the surrounding UI must be keyboard and screen-reader navigable.
Real-time travel information and disruption alerts
The EAA's transport scope explicitly includes delivery of transport service information including real-time travel information, with information screens limited to interactive screens located within the EU.
The key requirement is multi-channel delivery: the same information must be conveyed through more than one sensory channel. A platform change announced only on a visual departure board fails passengers who are blind or have low vision. A delay alert conveyed only through an audible announcement fails passengers who are deaf or hard of hearing. WCAG 1.3.3 (Sensory Characteristics) and 4.1.3 (Status Messages) are the operative criteria for the digital layer.
For apps and websites, disruption alerts must be exposed to assistive technology - typically via ARIA live regions - so that a screen-reader user receives the update without having to navigate to it manually. Push notifications must carry accessible text; an icon-only notification fails.
Self-service terminals and station kiosks
Terminal accessibility is a distinct topic with its own hardware and software requirements under EN 301 549 clauses 5 and 8. We cover it in full in our self-service terminal accessibility guide. Note the scope point: unlike the other digital elements, self-service terminals are in scope for all transport modes including urban, suburban and regional services.
The technical standard: EN 301 549 and WCAG 2.1 AA
A structured audit against EN 301 549 v3.2.1 is the recommended starting point for achieving EAA compliance. EN 301 549 is the harmonised standard that creates a presumption of conformity with the EAA. It incorporates WCAG 2.1 Level AA for web and mobile interfaces and extends beyond web content to cover non-web software, non-web documents (including PDFs), and hardware (relevant for kiosks). See our EN 301 549 guide for a full clause-by-clause breakdown.
WCAG 2.2 is backwards-compatible with WCAG 2.1 AA, meaning targeting 2.2 now creates no compliance conflict and future-proofs against an expected EN 301 549 update incorporating WCAG 2.2. The new WCAG 2.2 criteria most relevant to transport booking - SC 3.3.7 (Redundant Entry) and SC 3.3.8 (Accessible Authentication) - are Level A and Level AA respectively, placing them squarely within the EAA's operative benchmark.
The EAA's transport obligations sit alongside, not instead of, the EU passenger-rights framework. The passenger-rights framework comprises Regulation (EC) No 1107/2006 (air), Regulation (EC) No 1371/2007 as replaced by Regulation (EU) No 2021/782 (rail), Regulation (EU) No 1177/2010 (waterborne), and Regulation (EU) No 181/2011 (bus and coach). These regulations govern the physical assistance obligations; the EAA governs the digital channel through which passengers exercise those rights. Non-compliance with the EAA does not extinguish a passenger-rights obligation, and vice versa.
Enforcement reality in 2026
The Irish Aviation Authority (IAA) is the designated compliance authority for the accessibility of digital services provided by airlines operating in Ireland. The IAA's monitoring programme is one of the most explicitly scoped in the EU: the IAA is undertaking compliance monitoring in relation to: whether airline websites are accessible; whether mobile applications are accessible; whether electronic tickets and ticketing services are accessible; whether transport service information including real-time information is accessible; and whether interactive self-service terminals in Ireland are accessible. That list maps almost exactly to the EAA's transport scope - and it is already operational.
Transportation booking services face heavy scrutiny across all EU countries, with airlines, train operators, and ride-sharing apps subject to active enforcement.
On penalties: fines vary by country, from €60,000 in Ireland to approximately €900,000 in Sweden. Sweden's maximum fines reach SEK 10 million (approximately €900,000) with market ban authority. Financial penalties are not the only risk. Financial penalties are only one risk; depending on the member state, non-compliance can trigger product or service withdrawal from market. For a detailed country-by-country breakdown, see our EAA fines and penalties guide.
Enforcement patterns suggest regulators will prioritise remediation over immediate fines, but escalation is built into every member state framework. The practical sequence is: complaint or surveillance scan -> compliance notice -> corrective-action deadline -> escalation. Operators who respond promptly and document remediation work are in a materially better position than those who do not.
Prioritised remediation order
Not all failures block passengers equally. The following order is based on the proportion of users who are entirely prevented from completing a journey stage versus those who are merely inconvenienced.
A keyboard-inaccessible date picker or seat map blocks the entire journey for users who cannot use a mouse — screen-reader users, switch-access users, and many motor-impaired users. This is a complete blocker. Audit the critical path (search → select → pay) with keyboard-only navigation before anything else.
A barcode-only or untagged-PDF ticket blocks a passenger at the gate — the last point at which the failure becomes visible and the hardest point at which to recover. Add accessible text to all ticket formats. Tag PDFs. Set wallet pass field labels. This is a high-impact, relatively low-effort fix.
An inaccessible assistance-request form blocks a passenger from exercising rights under both the EAA and the passenger-rights regulations simultaneously. Remove inaccessible CAPTCHAs, ensure all form fields have programmatic labels, and confirm that submission confirmation is exposed to assistive technology.
Platform changes and delay alerts that are visual-only or audio-only fail a significant proportion of passengers at the moment of highest stress. Implement ARIA live regions for app/web alerts. Ensure push notifications carry accessible text. This is also the element most likely to generate complaints, since failures are immediate and visible.
SC 2.2.1 (seat-hold timers), SC 3.3.7 (redundant entry), and SC 3.3.8 (accessible authentication) are the WCAG 2.2 additions most likely to cause abandonment rather than complete blockage. Fix them after the complete-blocker issues, but before the next release cycle.
Online check-in and mobile boarding passes are secondary booking funnels. They often use different component implementations from the main booking flow and are frequently missed in audits. Include them explicitly in scope.
A note for operators procuring third-party systems
Most operators do not build their booking engine, passenger service system (PSS), app shell, or disruption-messaging platform in-house. The EAA obligation runs to the service as experienced by the passenger - not to the component that caused the failure. A booking engine that fails WCAG 2.1 AA is your compliance problem, not your vendor's.
The practical mitigation is contractual: require an Accessibility Conformance Report (ACR) tested against EN 301 549 before signing, and include accessibility maintenance obligations and re-testing rights in the contract. Our ACR/VPAT procurement guide covers what to ask for and how to evaluate what you receive.
Summary
The EAA's transport scope is precise: long-distance and interurban air, bus, rail and waterborne operators must make their websites, mobile apps, e-ticketing, real-time information, and self-service terminals accessible. Urban and suburban operators face a narrower obligation - terminals only - under the EAA's transport provisions, though other obligations may apply.
The failure modes that matter most are the ones that block passengers entirely: inaccessible booking funnels, barcode-only tickets, inaccessible assistance-request forms, and visual-only disruption alerts. Enforcement is operational - the IAA is already monitoring airline digital accessibility in Ireland, and transport booking services face active scrutiny across the EU. The remediation order above reflects where to put engineering effort first.
Related reading
Your Design System Is Your Accessibility Infrastructure: An Operating Model for 2026
95.9% of the web still fails WCAG. The bottleneck isn't detection - it's organisational capacity to act. A design system is the only place where one accessibility decision propagates everywhere.
Cookie Banner Accessibility: Why Your Vendor's Conformance Claim Doesn't Protect You
Your site may pass an audit and still block every keyboard user at the front door. The consent banner, chat widget, and payment iframe are someone else's code - but your legal liability.
Screen Reader Testing: A Protocol That Produces Comparable Results Release to Release
Automated tools find markup absences, not usability failures. This protocol covers which AT/browser pairs to test, in what order, and a fixed script that gives you comparable results every release.