1. Our commitment

Accessibility is treated as a quality dimension equal to performance and security. Every shipped change is reviewed for keyboard reachability, focus visibility, colour contrast, and screen-reader behaviour. We don’t treat accessibility as optional or as something to bolt on at the end.

2. The standard we target

Our internal target is WCAG 2.2 Level AA. We also adhere to the following success criteria above AA:

• 2.5.5 Target Size (Enhanced, AAA) — interactive controls aim for at least 44×44 CSS pixels (Apple HIG / WCAG 2.5.5 AAA).
• 2.3.3 Animation from Interactions — animations respect prefers-reduced-motion: reduce.
• 1.4.3 Contrast (Minimum) — body text and interactive controls meet or exceed AA contrast ratios; we use brand tokens with measured contrast values.

3. What works well today

• Keyboard navigation. Booking, account, and checkout flows are traversable with Tab / Shift-Tab; focus rings are visible on every focusable element. Skip-to-content links are present at the top of each page.
• Screen readers. Pages use semantic landmarks (header, main, nav, footer, article) so VoiceOver, NVDA, and JAWS can announce structure correctly.
• Image alt text. Every meaningful image carries descriptive alt text; decorative images carry empty alt + aria-hidden=“true”.
• Forms. All form controls have associated labels; errors are announced via aria-live regions.
• Reduced motion. Hover-only animations, carousels with auto-play, and decorative parallax are disabled when the user prefers reduced motion.
• Colour contrast. Brand palette pairings are audited for AA contrast against cream and white backgrounds.

4. Known gaps

Honestly:

• Hotel map interactions. The hotel-detail map is provided by a third-party library and is not yet fully keyboard-navigable. Zoom and pan require mouse / touch.
• Date pickers. Our flight and hotel date pickers are keyboard usable but the announcement experience on screen readers is being improved.
• Comprehensive contrast audit.We’ve audited the main flows but secondary surfaces (admin pages, edge-case empty states) haven’t had a full pass.
• Third-party widgets.The Stripe-hosted payment form and the embedded LiteAPI hotel-payment widget follow their own accessibility programs; we’ll continue to track their improvements.

5. Reporting an accessibility barrier

If you encounter content that’s difficult or impossible to use, please tell us. We treat accessibility barrier reports as high-priority bugs.

• Email [email protected]with subject “Accessibility”.
• Include the page URL, what you were trying to do, the assistive technology you were using (screen reader + version, etc.), and what happened.

We aim to acknowledge within 2 business days and to either fix the issue or provide a workaround within 30 days. Critical barriers (account access, payment) get faster treatment.

6. Alternative formats

If a key document on our site is inaccessible to you, we’ll provide an alternative format on request. For example: a plain-text version of a long policy, a phone-call walkthrough of the booking flow, or a manually-prepared itinerary email if the in-app receipt is hard to navigate.

7. Enforcement

As a US-headquartered company, we are subject to the Americans with Disabilities Act (ADA) Title III as it has been applied to websites by the U.S. Department of Justice. For customers in the European Union, the European Accessibility Act (Directive (EU) 2019/882)becomes generally enforceable from 28 June 2025; we are tracking the implementing rules of member states relevant to our planned EU launch.

8. Contact

Accessibility lead: [email protected]. You can also reach us via the contact form.