
Wheel the World Digital Accessibility Statement
Travel should be possible for everyone
Wheel the World's mission is to make accessible travel possible for every person. We are committed to designing and operating digital services that work for everyone — including travelers with mobility, vision, and hearing disabilities, senior travelers and the partners who serve them.
We continuously work to improve the accessibility of our digital services. This statement describes the standards we follow, the work we have completed, the work that is still in progress, and how to reach us when something does not work for you.
Description of services and accessibility measures
This statement applies to the following digital experiences operated by Wheel the World:
wheeltheworld.com — our public site for searching and booking accessible hotels, tours, and experiences.
portal.wheeltheworld.com — our partners portal, where hotels, restaurants, activities and destinations access the accessibility information we have mapped about their venues.
Third-party booking flows and partner-hosted content are outside the scope of this statement. We work with those partners to align with the same standard wherever we can.
We are voluntarily committed to working toward the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, the international technical standard for digital accessibility published by the W3C. We adopt this benchmark because it reflects the experience travelers with disabilities deserve.
WCAG is built on four principles that guide our work — content should be perceivable, interfaces should be operable, design should be understandable, and content should be robust enough to work with assistive technologies. We treat these as the direction we are moving in, not a state we have already reached. Where we are today against this standard is described in the next section.
To work toward this objective, we have put the following measures in place:
Text-based descriptions. Detailed accessibility information in clear, simple language for the venues in our marketplace.
Image alternative text. Descriptive alt text generated through a hybrid process: our content operations team writes and reviews alt text, supported by an AI vision model that suggests drafts at the scale we need to cover thousands of venues.
Captions on videos. Captions on the videos we host directly.
Text resize. Text on the public homepage can be resized up to 200% without the layout breaking.
Keyboard navigation. The public homepage has been tested manually for keyboard-only operation.
Structured accessibility information. Information for the venues in our marketplace is organized by mobility, vision, hearing, and cognitive criteria — so the answer to "can I stay here?" is in the listing, not in a phone call.
Where we are today
We are partially conformant with WCAG 2.2 Level AA. Partially conformant means most parts of the experience meet the standard, and parts of the experience do not yet.
Our roadmap focuses on the foundations that have to be right everywhere — HTML landmarks, focus order, image alternative text, and ARIA roles — landing first on the public homepage, then expanding outward. We publish progress updates when we have meaningful changes to share rather than committing to fixed completion dates, because we would rather ship genuine fixes than rush toward a number.
Training and education
At Wheel the World, accessibility is part of how we work, not a specialty held by a few people. All Wheel the World employees complete accessibility training within their first two weeks at the company, as a required part of onboarding. We cannot build for accessible travel if accessibility is not a shared competency across the team.
We also maintain internal accessibility guidelines that serve as a reference for ongoing work across the company.
Inclusive design, research, and writing practices
We aim to consider accessibility from the start of the product lifecycle, supported by the following practices:
Accessible design system. Our component library is being migrated to incorporate accessibility requirements as built-in defaults, so consistency across the platform improves as components propagate.
Inclusive user research. We run sessions with travelers with disabilities — including travelers using mobility aids, blind and low-vision travelers, and travelers who are deaf or hard of hearing. Their feedback informs our roadmap and the way we redesign flows and screens.
Accessibility in the design process. Our design and engineering workflow is moving toward documenting accessibility requirements (semantics, keyboard behavior, screen reader expectations) at the design stage, before development begins.
Testing and quality assurance
We integrate accessibility testing into our development and quality assurance processes:
Automated tests. We run Stark automated scans regularly across the public site and the partners portal to detect accessibility issues across our platform.
Manual testing. Our accessibility lead performs manual keyboard testing of the homepage as part of the current foundations work. Manual coverage will expand as the foundations stabilize and propagate to other templates.
Assistive technology testing. We do not yet run our own screen reader test matrix. We are deliberately starting with the foundations — landmarks, focus order, alt text, and ARIA roles — so that when assistive technology reaches our pages, it has something correct to read. Testing against specific screen readers (VoiceOver, NVDA, JAWS, TalkBack) is on our roadmap, not a current capability.
Audits and evaluation
We carry out internal audits to understand our performance and prioritize fixes:
Internal audits. Our accessibility lead and engineering team review audit results regularly across the public site and the partners portal.
Issue tracking. Issues identified through audits and user reports are tracked against our WCAG 2.2 AA backlog.
Statement maintenance. This statement is reviewed whenever we make significant changes to the platform. The most recent version posted at this URL governs.
Centralized accessibility support
Accessibility at Wheel the World is led by a dedicated accessibility lead and reviewed across product, design, and engineering. We do not rely on a single tool. Behind the scenes, the public site and the partners portal share a design system that is currently being migrated. As more components move into the shared library, accessibility fixes apply once and propagate everywhere — which is why we are investing in the foundations before chasing every individual violation.
Compatibility
We design and test our website for the latest two versions of Chrome, Edge, Firefox, and Safari on desktop and mobile. Compatibility with assistive technologies — screen readers, switch access, voice control, and others — is not yet part of our regular test matrix. Our first priority is making sure the underlying structure of our pages is correct (landmarks, headings, accessible names, focus order) so that assistive technology has something well-formed to work with. A formal AT compatibility program is on our roadmap.
What we know is not there yet
We would rather be honest than perfect-sounding. As of the date of this statement, these are the gaps we are tracking, mapped to the WCAG criteria we are working against:
Some interactive elements (custom buttons, icon controls) do not expose a clear accessible name to assistive technology — WCAG 4.1.2 Name, Role, Value.
"Skip to content" bypass blocks are not yet present on every template, especially in the partners portal — WCAG 2.4.1 Bypass Blocks.
Some content does not survive user-defined text spacing without clipping or overlap — WCAG 1.4.12 Text Spacing.
A small number of color combinations fall below the 4.5:1 contrast ratio required at AA — WCAG 1.4.3 Contrast (Minimum).
Some images on listing pages are missing meaningful alternative text — WCAG 1.1.1 Non-text Content.
Lists and tables in some content pages use markup that does not fully convey structure to assistive technology — WCAG 1.3.1 Info and Relationships.
Certain dropdown menus and modals are not yet fully operable from the keyboard, and some focus indicators are missing — WCAG 2.1.1 and 2.4.7.
Some embedded third-party widgets (such as maps and payment) inherit the accessibility level of the upstream provider.
Items in the homepage scope have an owner and a target. The rest are tracked in the same backlog and prioritized as engineering capacity opens up. If you hit one of these and it blocks you, please tell us — your report helps us prioritize.
Feedback and contact information
We work to make our digital services accessible to all our users, but there may be limitations. If you hit an accessibility barrier on Wheel the World, please reach out. We prioritize the accessibility reports we receive against our WCAG 2.2 AA backlog.
Email:
We acknowledge reports we receive at this address and share what we find. As the channel matures we will publish concrete response times here; for now we would rather not promise a number we cannot defend.
When you write to us, it helps to include the page URL, the assistive technology and browser you were using, and a short description of what happened — but none of that is required. A one-line message is enough to start.
Information you send to this address is processed under our Privacy Policy.
Formal approval
This statement was prepared following W3C guidance on accessibility statements and reflects an internal review of our digital experiences against WCAG 2.1 Level AA. It is reviewed whenever we make significant changes to the platform. We may update this statement at any time; the most recent version posted at this URL governs.
- Statement prepared
- Last reviewed
- Approved by
- The Wheel the World Accessibility Lead and product leadership
- Standard
- WCAG 2.1, Level AA