Cruise app accessibility in 2026: ADA as a release gate
TL;DR
Cruise app accessibility in 2026 is a release condition: an app that breaks at 200% text size or with a screen reader on does not ship. We built a four-gate release check for React Native cruise apps from WCAG 2.2, the European Accessibility Act and platform guidance. The 200% text gate comes first, because it breaks the most layouts and serves the largest group: 34% of ocean cruisers in 2025 were over 60, per CLIA.
- The EAA covers websites, mobile apps and e-tickets of waterborne passenger transport services provided after June 28, 2025.
- React Native scales text by default, so a fixed-height card clips the dinner time at 200% unless someone tests it.
- Screen reader checks run on VoiceOver and TalkBack as two passes, because iOS and Android fail in different places.
Who sails, and why accessibility is a cruise problem
CLIA counted a record 37.3 million ocean cruise passengers in 2025, in its 2025 global market report. The average cruiser was 46.7 years old, and 34% were over 60. Disability rises with age: the CDC's prevalence data puts it at 1 in 4 US adults and about 2 in 5 adults aged 65 and older. Most never call it a disability; they just raise the system text size.
The law reached ships two decades ago. In Spector v. Norwegian Cruise Line, decided on June 6, 2005, the US Supreme Court held that Title III of the ADA applies to foreign-flag cruise ships in US waters, except where it would regulate a vessel's internal affairs. UsableNet's 2025 year-end report counted 5,114 ADA digital accessibility lawsuits filed in 2025, across websites, mobile apps and video, with travel and hospitality drawing 1% of them.
Three dates that made accessibility a release condition
June 28, 2025. The European Accessibility Act applies to services provided to consumers after that date, and Article 2 names waterborne passenger transport. Covered elements include websites, mobile applications, electronic tickets and real-time travel information.
May 13, 2025. Apple announced Accessibility Nutrition Labels, a section on App Store product pages that shows support for VoiceOver, Voice Control, Larger Text, Sufficient Contrast, Reduced Motion and captions. Apple's App Store Connect help says the labels are voluntary to start and will be required for new apps and updates over time.
April 20, 2026. The US Department of Justice published an interim final rule moving its Title II web and app deadlines to April 26, 2027 for large public entities and April 26, 2028 for smaller ones. Title II covers state and local governments; cruise lines sit under Title III. The rule still matters, because its standard is WCAG 2.1 Level AA, the benchmark auditors bring to private apps too.
How we built the gate
A release gate is a check that blocks the build when it fails. Each of our four had to clear three tests:
- It maps to a WCAG 2.2 success criterion at Level AA, or to written iOS or Android guidance.
- A QA engineer can run it on two phones each release, with no specialist tooling.
- It catches a failure we have seen in cruise app builds, or one the platform documents.
The order follows reach: how many guests a failure blocks. We started from the three pages that rank for this topic: OnDeck's cruise app accessibility post, Accessible Minds' travel accessibility page and building ONE's cruise ship consulting page. None names the 200% requirement or React Native.
Mercury Development wrote this guide and builds cruise apps. WCAG facts come from WCAG 2.2, a W3C Recommendation since October 5, 2023, updated on December 12, 2024. Platform facts come from vendor documentation opened on November 9, 2026. Any group in our own data with fewer than three data points is not published.
The release gate at a glance
| Gate | WCAG 2.2 criterion | Pass condition | Device check |
|---|---|---|---|
| 1. 200% text | 1.4.4 Resize Text, 1.4.10 Reflow | No clipped, overlapping or hidden text at the largest system size | iOS Larger Text and Android font scale at 200% |
| 2. Screen readers | 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value | Every guest path completes with eyes off the screen | VoiceOver and TalkBack, as separate passes |
| 3. React Native defaults | 4.1.2 Name, Role, Value, 2.4.3 Focus Order | Every touchable has a label and a role; sheets hold focus | Code review plus Accessibility Scanner |
| 4. Targets and contrast | 2.5.8 Target Size (Minimum), 1.4.3 Contrast (Minimum) | Targets at least 24 by 24 CSS px, primary actions at platform size; text at 4.5:1 | Accessibility Scanner and a contrast checker |
Gate 1: 200% text with nothing lost
WCAG 1.4.4 asks that text resize up to 200 percent without loss of content or functionality, which W3C's Understanding note reads as twice the width and height. Both platforms reach it. Android 14 supports font scaling up to 200% on a nonlinear curve, and Apple's Human Interface Guidelines ask apps to let people enlarge text by at least 200 percent.
React Native follows the system by default. On the Text component, allowFontScaling defaults to true, and maxFontSizeMultiplier caps growth. Two habits break cruise apps. A team turns scaling off on crowded screens, which fails the guests who raised their text size on purpose. Or it leaves scaling on inside fixed-height cards, and at 200% the deck number or the show time gets cut off.
Pass condition: set both phones to the largest standard size, then walk the boarding pass, the daily planner, a dining reservation and a payment. Nothing clipped, nothing overlapping, nothing pushed off screen. WCAG 1.4.10 adds reflow: content usable at 320 CSS pixels wide without scrolling in two directions.
Gate 2: screen readers on every guest path
A screen reader user hears your app in the order the code exposes it. React Native's accessibility API gives you the parts: accessibilityLabel says what an element is, accessibilityRole says what it does, accessibilityState reports selected or disabled.
Test VoiceOver and TalkBack as two passes. Some props are platform-specific, accessibilityViewIsModal for iOS and importantForAccessibility for Android, so one component can read well on one phone and badly on the other. Bottom sheets show it first. If focus escapes to the screen behind a sheet, a TalkBack user swipes into a menu they cannot see.
Pass condition: with your eyes off the screen, complete online check-in, book tonight's show and open the boarding pass. Each control announces a name and a role, and focus follows every sheet in and out.
Gate 3: React Native defaults that fail review
Most React Native accessibility failures are omissions. A Pressable around an icon has no label, so the screen reader says "button" and nothing more. A custom tab bar built from plain views has no tab role. A ship map shipped as one image gives the screen reader nothing, and its baked-in text does not grow at 200%.
Two cheap checks catch most of this. In code review, reject any touchable without an accessibilityLabel and an accessibilityRole. On device, run Google's Accessibility Scanner, which scans a screen and suggests fixes for labels, target sizes and contrast.
Pass condition: zero unlabeled touchables in the diff, and no new Accessibility Scanner findings on changed screens.
Gate 4: targets and contrast for older guests
Small targets fail guests with tremor, and on a moving ship they fail everyone else too. WCAG 2.5.8 sets a floor of 24 by 24 CSS pixels for pointer targets. Android recommends at least 48dp by 48dp, and Apple lists 44 by 44 points as the default iOS control size. WCAG 1.4.3 asks for contrast of at least 4.5:1 for normal text. Pastel brand palettes often miss it.
Pass condition: primary actions at 48dp on Android and 44 points on iOS, nothing under 24 by 24 CSS pixels anywhere, every text style at 4.5:1 or better.
Which gates fit which app
| App or flow | Gates every release | Why |
|---|---|---|
| Pre-cruise guest app: booking, check-in, documents | All four | EU sales put it under the EAA, and US guests can sue under Title III |
| Onboard guest app: planner, dining, ship map, chat | All four, Gate 2 on map and chat | Guests use it on the move, often at maximum text size |
| Booking widgets on partner sites | Gates 1, 2 and 4, in a browser | WCAG applies to web content directly |
| Crew and staff apps | Gates 3 and 4 | Staff work fast, often one-handed, on a moving deck |
What our cruise programs taught us
Mercury Development builds cruise software for cruise line clients it cannot name under NDA. In those programs, ADA and PCI DSS were release conditions: a build that failed either one did not go to the stores. The passenger app was rebuilt on React Native from the ground up rather than ported, and accessibility had to be in the first release, with text zoom and screen reader behavior on the acceptance list.
Three patterns repeat:
- Legal reviews the release, so accessibility findings hold the build.
- Android screen reader behavior needs its own budget. Bottom sheets that read correctly in VoiceOver needed separate work for TalkBack.
- A real sailing finds what the office misses. Feedback from a cruise reported navigation buttons too small to tap, which no emulator pass had flagged. See our guide to testing cruise apps on a real vessel.
For OneSpaWorld, which describes itself as an operator of health and wellness centers onboard cruise ships, we built an onboard spa platform that has run since 2018 on over 160 ships operated by multiple cruise lines. Staff reach it on Android tablets in kiosk mode, where target size decides how fast a spa desk moves.
Mercury Development has built software since 1999 with 500+ engineers. We build to WCAG 2 AA and ADA requirements, as our accessibility practice sets out, and work under work-for-hire, so the customer owns the code and all underlying IP.
Put accessibility in the build, before the audit
Opinion, with the mechanism.
Most cruise lines buy accessibility as an audit of a finished release. By then every fix competes with the launch date, and the launch date usually wins. Move the four gates into the definition of done. A story that adds a screen ships with its labels, its roles and a 200% screenshot from both platforms, or it does not merge.
Then change the vendor interview. Hand over a phone and ask: "Set the largest text, turn on TalkBack and open the boarding pass from your last release." A team that builds to the gate shows you a working screen. Others show you a policy.
Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The release records from Mercury Development's cruise programs behind this article sit in the delivery operations he oversees.
Planning an accessible cruise app release? Start with your riskiest flows
Send us the guest flows you plan to ship next: check-in, boarding pass, planner, dining or payments. We will check them against the four gates on your current build and tell you which failures block a release and which can wait.