Performance & Accessibility for Travel and Tourism
Follow an illustrative travel project from slow galleries and broken date pickers to faster, accessible booking, with the rules, seasons and costs involved.
Last revised
Performance & accessibility for travel and tourism is about keeping a traveler moving from inspiration to payment on whatever device and connection they happen to have. That means destination and booking pages that load quickly, image galleries that do not swallow a roaming data allowance, date and passenger pickers that work with a keyboard and a screen reader, and a booking flow that survives a slow hotel network or a patchy signal on a train. Travel buyers take their time, compare several tabs at once and return more than once before they commit, so every slow step or blocked control is another chance for them to finish the purchase somewhere else.
This page follows one illustrative project from start to finish. The business, its numbers and its results are an invented example, built to be typical of a small-to-mid-sized tour operator with its own lodging, and labeled that way throughout. It is not a client story and none of its figures are measurements from real work. The point is to show how the work actually runs: how you find where bookings leak, what an audit turns up in a travel booking path, how fixes are sequenced around booking seasons, what drives the cost, how to brief a supplier and how to judge the outcome honestly.
Travel is also a regulated space. Airlines, hotels and anyone advertising fares or room prices have specific federal obligations that touch the booking interface directly. We summarize the ones that most often matter below. This is a practical note, not legal advice, and the rules change, so check current guidance from the agencies themselves and your own counsel before relying on any of it.
Where travel booking paths lose people
The travel customer's situation is different from almost any other online buyer's. The consideration cycle is long, the visual competition is heavy, and the booking path has to survive comparison shopping against aggregators, online travel agencies and the supplier's own rivals. A traveler may browse destination photography and itinerary content for weeks on a laptop at home, then make the final decision on a phone in an airport lounge, or book the next leg of a trip on roaming data in a town with one bar of signal.
That produces a recognizable set of failures:
- Destination pages that are too heavy for the network they are read on. Full-screen carousels, autoplaying drone video and uncompressed photography look superb on office broadband and fail on roaming data, which is exactly how many travelers browse during a trip.
- Booking engines bolted on from outside. Tour, activity and hotel booking engines are usually third-party widgets or hosted pages with their own scripts, styles and accessibility quality, sitting inside a site that the brand controls.
- Calendars and pickers that only work with a mouse or a finger. Date grids with no keyboard support, passenger counters that are unlabeled "+" and "-" icons, room selectors that open in a layer screen readers never reach.
- Prices that change without warning. A price that jumps when the passenger count changes, or grows when mandatory fees appear on the last step, is both a conversion problem and, in some parts of travel, a legal one.
- Time limits and security checks. Session timeouts on seat or room holds, and puzzle-style verification challenges, that stop people who read, type or navigate more slowly.
The rules that shape a travel booking interface
Airlines and the Air Carrier Access Act
Airlines must meet accessibility requirements for their websites under the Air Carrier Access Act. The Department of Transportation's rule requires covered US and foreign carriers' primary websites that market to US consumers to conform to WCAG 2.0 Level AA, and it sets related obligations for ticket agents and for airport kiosks. The regulation names WCAG 2.0, but WCAG 2.2 is the current version of the guidelines and meeting it also covers the earlier criteria. Airline teams should read our note on air travel website accessibility for the decisions specific to carriers.
Hotels and ADA reservation rules
Hotels have their own ADA reservation rules. Under the Department of Justice's regulations, lodging operators must let guests with disabilities reserve accessible rooms in the same ways and during the same hours as other guests, describe the accessible features of the hotel and its rooms in enough detail for a guest to judge whether a room meets their needs, hold accessible rooms for guests who need them, and block the specific accessible room once it is booked. Those duties reach the online booking path, including the information you supply to third-party booking channels. The Department of Justice publishes its guidance on ADA.gov. Booking interfaces also carry broader ADA obligations that have been litigated repeatedly against travel sites.
Full-fare advertising and baggage fee disclosure
Department of Transportation rules require full-fare advertising for air travel, so a price shown without mandatory taxes and fees is a violation rather than a marketing choice. That applies to airlines and ticket agents, and it also applies when a tour package that includes air is advertised with a price. The DOT also regulates how baggage fees are disclosed. From an interface point of view, the lesson is that the total price must be present and readable, including to screen reader users, wherever a fare is advertised, not only on the final step.
Fees and bait pricing more broadly
The FTC pursues bait pricing more widely under its general authority over unfair and deceptive practices. Its rule on unfair or deceptive fees applies specifically to live-event tickets and short-term lodging, which includes hotels and vacation rentals: where a price is shown, the total price including mandatory fees has to be displayed clearly and more prominently than other pricing information. Read the rule and the current business guidance from the FTC before changing how your room rates are displayed. In accessibility terms, a total that is visually prominent but announced after a string of other numbers, or hidden in a tooltip, defeats the purpose.
Note: Everything from here on follows an illustrative project. The operator, its traffic, its page weights and its results are invented to show how the work runs and how to read the numbers. They are not measurements from a real client, and your own figures will be different.
The illustrative project: a coastal tour operator with its own lodge
Picture a regional operator on a popular stretch of coast. It sells three kinds of product: guided day tours (boat trips, walking tours, food tours), multi-day packages that combine tours with lodging, and rooms at its own small lodge. About half its visitors come from overseas. Its website is a modern content management system with a strong visual design, destination pages for each town it serves, and a third-party tour booking engine embedded in the tour pages. Lodge rooms are sold through a separate hotel booking engine that opens in an overlay.
The person who owns the problem is the digital lead, who is responsible for online revenue. What they watch is how many started bookings reach payment, especially on phones abroad. Their analytics show that phone visitors start plenty of bookings but reach the payment step far less often than desktop visitors, and that visitors from overseas on phones do worst. Customer service has also logged a handful of emails from people who could not choose dates, including one from a customer who uses a screen reader and said the calendar "does nothing."
The business is ahead of its main booking season, which for this illustrative operator runs from late winter, when people plan summer trips, through early summer, with a second smaller surge in early fall for shoulder-season breaks. That gives the project a window of a few months before the traffic peaks.
Finding the leak before touching any code
The first job is to find out where people actually stop, on which devices and in which conditions. Guessing is expensive, and in travel it usually points at the wrong place, because a pretty gallery that is slow on roaming data and a calendar that screen readers cannot operate both show up in analytics simply as "left the page."
The funnel, split the way travelers actually differ
The illustrative operator's booking funnel is set up in analytics with the steps that matter: tour or room page viewed, dates chosen, travelers chosen, extras chosen, traveler details entered, payment page reached, booking confirmed. It is then split three ways: by device, by visitor country (as a rough proxy for "traveling now" versus "planning from home"), and by whether the visitor arrived on a destination page or directly on a tour page. The largest drop for phone visitors is between viewing the tour page and choosing dates. That points at two suspects: the page is too slow to become usable, or the date picker is hard to use.
Field performance data
Next come Core Web Vitals from real visitors, taken from the Chrome User Experience Report and from the operator's own real-user monitoring. Largest Contentful Paint (when the main content appears), Interaction to Next Paint (how fast the page responds to a tap or key press, the metric that replaced First Input Delay as a Core Web Vital in March 2024) and Cumulative Layout Shift (how much the layout jumps) are all read at the 75th percentile. On phones, destination pages and tour pages are well outside the "good" range for Largest Contentful Paint, and the tour page's Interaction to Next Paint is poor, mostly when someone opens the calendar.
Watching real use
Finally, the team books a tour on a mid-range Android phone with a throttled connection, then on an iPhone with VoiceOver, then on a laptop with only the keyboard. This is where the specific failures appear, and they become the audit's starting list.
What the audit found on destination pages and galleries
Performance problems on travel sites nearly always start with imagery. The fix is not fewer images; photography and video are what sell a destination. It is sending each device the image it needs, when it needs it. For the photography side of that, our work on photography and visuals for travel and tourism covers how to produce imagery that stays sharp at sensible file sizes.
The illustrative findings looked like this:
- Each destination page opened with a carousel of eight full-resolution photographs, all loaded at once, with the first slide being the Largest Contentful Paint element.
- A background drone video on the home page autoplayed and looped with no pause control.
- Gallery images below the fold were not lazy-loaded, and images were served in older formats at desktop dimensions to phones.
- A map embed, a reviews widget, a chat widget and the booking engine's script all loaded on every destination page, even though bookings happened on the tour pages.
- Web fonts were loaded from several families and weights, causing text to reflow as they arrived.
Accessibility issues on these pages were real but smaller: carousel controls without accessible names, photographs with file names as alternative text, low contrast for text laid over photos, and an auto-advancing carousel with no way to pause it. Moving content that starts automatically and lasts more than five seconds needs a pause, stop or hide mechanism under WCAG.
What the audit found in date, passenger and room pickers
The booking engine is where the most serious barriers sat, as it is on most travel sites. Pickers are some of the hardest components to build accessibly, and booking engine vendors vary widely in how well they do it.
| Component | Illustrative finding | Severity | Who fixes it |
|---|---|---|---|
| Tour date calendar | Days are clickable elements with no keyboard support; screen readers hear a grid of numbers with no month, weekday or availability | Blocker | Booking engine vendor |
| Passenger counter | "+" and "-" buttons have no accessible name; the new count is not announced | High | Booking engine vendor |
| Room selector overlay | Focus stays behind the overlay; Escape does not close it | High | Hotel engine vendor and operator's site code |
| Price summary | Sticky summary bar covers the focused field on small screens; total updates silently | Medium | Booking engine vendor |
| Traveler details form | Lead traveler's details must be retyped for each tour in a package | Medium | Booking engine vendor |
| Accessible room information | Accessible room features described only as "accessible room available" | High | Operator content |
| Hold timer | Room hold expires with no warning and no way to extend | Medium | Hotel engine vendor |
Several of these map directly to success criteria added in WCAG 2.2. A sticky price bar that hides the field with keyboard focus runs into Focus Not Obscured. Asking the lead traveler to type the same name and email again for each part of a package runs into Redundant Entry. A price range slider that can only be operated by dragging needs a single-pointer alternative under Dragging Movements, and small "+" and "-" buttons have to meet the Target Size minimum of 24 by 24 CSS pixels or be spaced so that they effectively do. If the booking engine used a puzzle-style verification challenge before payment, Accessible Authentication would apply as well.
Two older criteria also matter in booking. Timing Adjustable requires that people be warned before a time limit ends and be able to extend it, unless the limit is essential; many room and seat holds can offer an extension even when inventory is tight. Status Messages requires that updates such as a new total price or "only two rooms left" be announced to screen reader users without moving their focus. For destination search boxes that suggest places as people type, our guide to accessible autocomplete fields covers the patterns that hold up.
The accessible room description is worth singling out because it is entirely in the operator's hands. The hotel reservation rules expect enough detail for a guest to decide whether a room meets their needs: for example, whether the bathroom has a roll-in shower or a tub with grab bars, door widths, bed height and which features are in which room types. That is a content job, not a code job, and it can be done in days.
How the remediation ran
With findings in hand, the fixes were split by owner and sequenced so that the most valuable, lowest-risk changes went live first and nothing risky landed during the booking peak.
- Agree the priority order. Blockers in the booking path first, then the performance of tour pages, then destination pages, then everything else. The digital lead signs off the order, because they own the revenue at stake.
- Fix what the operator owns. Resize and reformat images, lazy-load galleries, replace the looping video with a poster image and a play button, load the map, chat and booking scripts only on pages that use them, trim fonts, name the carousel controls and add a pause button, write real alternative text and detailed accessible room descriptions.
- Escalate what vendors own, with evidence. Write each booking engine issue as a reproducible report: steps, expected behavior, actual behavior, the WCAG 2.2 criterion affected and a short screen recording. Ask each vendor for a timeline and for their accessibility conformance report.
- Put a wrapper around what vendors will not fix quickly. Where the operator's code controls the container, fix focus handling and the Escape key on the room overlay from the site side, and offer a clearly labeled alternative booking route by phone or email, staffed during the hours the site is available, for anyone who hits a barrier in the meantime.
- Retest on real devices. Repeat the original bookings on a throttled Android phone, with VoiceOver and TalkBack, and with a keyboard only, and confirm field data trends in the right direction over the following weeks.
- Freeze and watch. Stop non-essential changes to booking pages ahead of the peak, and review the funnel and field data weekly until it ends.
The vendor step is often the slowest, because the fix ships on the vendor's release schedule rather than yours. In this illustrative project, the tour booking engine vendor fixed the passenger counter quickly but needed a later release for the calendar. That is a common pattern, and it is why the escalation goes out in the first days of the project rather than after the operator's own fixes are done.
Automated scanning ran alongside the manual testing to catch regressions, such as a new image uploaded without alternative text. Our note on automated accessibility testing explains what scanners catch and what they miss; in booking flows, most of what matters sits in the part they miss.
Scheduling the work around booking seasons
This work happens before booking seasons, and whenever a new booking provider or widget is added. The booking season is not the travel season: for many summer destinations, people book in late winter and spring; for winter sports destinations, in late summer and fall; for holiday travel, well ahead of the dates themselves. Plan backward from when people book, not from when they arrive.
| Travel business | When customers tend to book | When to audit and fix | When to freeze |
|---|---|---|---|
| Summer coastal and island tours | Late winter through spring | Fall and early winter | From the start of the main booking surge |
| Ski and winter lodges | Late summer through fall | Spring and early summer | Before early-season deals launch |
| City breaks and events travel | Around event announcements and school holidays | In the gaps between major event on-sales | Around each on-sale or announcement |
| Cruises and long-haul packages | Often many months ahead, with early-year promotions in many markets | The quieter months before promotional pushes | During major promotions |
The second trigger, a new booking provider or widget, is easy to underestimate. Switching booking engines, adding a new activities marketplace, a new payment method or a new upsell widget can undo a year of performance and accessibility work in one release. Test any new provider's demo with a keyboard and a screen reader, and on a throttled phone, before you sign, and ask for its accessibility conformance report. Teams that ship often should build these checks into their normal sprint work, which our piece on accessibility in agile teams covers in detail.
The illustrative result, read carefully
Here is what the illustrative operator's numbers might look like once the fixes were live and field data had caught up. Remember that these are invented to show how to read an outcome; they are not a promise or a measurement of real work.
To put the last figure in context with a simple worked example: if the operator's phone visitors started 5,000 bookings in a month, a rate of 180 in every 1,000 means 900 reached payment, and a rate of 240 in every 1,000 means 1,200 did. That is 300 more travelers reaching the payment page in that hypothetical month. Whether they then complete the purchase depends on the payment step, prices and availability, so the honest claim is about reaching payment, not about revenue.
What the numbers do and do not show
Travel data is seasonal and noisy. A rate measured in March cannot be compared fairly with one from November, a competitor's sale can move comparison shoppers overnight, and a strong exchange rate can change overseas demand on its own. The fair comparison is the same weeks year over year, or a before-and-after window with no major promotion inside it, split by device and by visitor country. Keep a dated log of every fix and every vendor release so that changes in the funnel can be tied to specific changes on the site.
Accessibility progress needs its own measures, because a better booking rate does not tell you whether a screen reader user can now complete a booking. Track open issues on the booking path by severity, the number of blockers, and whether each core task can be completed with a keyboard and with screen readers on both mobile platforms. Our guide to measuring accessibility progress describes how to report this to people who are used to revenue dashboards.
Pros of fixing the booking path before a redesign
- Removes barriers for disabled travelers within weeks rather than a full rebuild cycle
- Protects the upcoming booking season's revenue
- Produces vendor evidence that informs whether to keep or replace a booking engine
- Teaches the team the standards a later redesign must meet
Cons
- Some vendor-owned issues may stay open until the vendor ships a fix
- Workarounds around third-party widgets need maintenance
- A dated design or platform may still limit performance after the quick wins
- Retesting after each vendor release adds recurring effort
What drives the cost of performance & accessibility for travel and tourism
Performance and accessibility work starts at $1,200.00 per audit with us. Every one of our rates is listed on the pricing page beside what the US market typically charges, and a quote narrows the range to a single number for your booking volume. What moves a travel project above the starting point is usually one of the following:
- Number of booking engines. Tours, activities, rooms, transfers and flights may each run through a different provider, and each needs its own walk-through.
- Languages and markets. Sites in several languages or currencies need spot checks per locale, since translations break layouts and price formatting changes what screen readers announce.
- Regulated pricing. Fare advertising and lodging fee display add review time to every page where a price appears.
- Template count. Destination, tour, package, room, blog and landing page templates each need testing, though one example of each template usually stands in for the rest.
- Retest cycles. A single retest after fixes is the minimum; retesting after each vendor release and before each booking season costs more and catches more.
If the audit shows that the site itself needs rebuilding, our web design and development for travel and tourism team can carry the findings into the new build so they do not have to be fixed twice. When you are ready for a firm number, a quote scopes it to your templates and providers.
How to brief a supplier for a travel site
A useful brief lets a supplier price the work accurately and start testing in the right place. For a travel business it should include:
- Your booking products and their engines. List every product type (tours, rooms, packages, transfers, flights) and which provider sells it, whether embedded, overlaid or on a separate hosted page.
- Your booking season calendar. When people book each product, when you run promotions, and when you can and cannot change the booking path.
- Your regulatory position. Whether you are an airline or ticket agent, whether you advertise air-inclusive packages, whether you sell lodging directly, and any complaints or demand letters received, shared with your counsel's agreement.
- Your funnel and field data. Analytics access with booking steps defined, split by device and country, and access to Core Web Vitals data.
- Your markets. Languages, currencies and the countries your visitors come from, so testing reflects real network conditions and locales.
- Your owners. Who signs off (typically the digital or e-commerce lead), who manages each vendor relationship, and who can change content such as accessible room descriptions.
When comparing suppliers, ask to see a sample finding written for a booking engine vendor, ask which screen readers and devices they test with, and ask how they will separate issues you own from issues your vendors own. A supplier who promises that a plugin will make your site conformant, or that their work will make you immune to claims, is promising something no one can deliver. If you are unsure whether a full audit is worth it yet, you can send a couple of your own files, such as a screen recording of your booking flow, and see what an initial look finds.
Verdict For most travel businesses, the fastest return comes from fixing the booking path and the images around it before the next booking season, not from a redesign. Lighten destination pages for roaming connections, make the date, passenger and room pickers work with a keyboard and a screen reader, show total prices clearly wherever they appear, and hold vendors to the same standard as your own code. Then measure starts reaching payment by device and country, season against season.
Keeping the booking path healthy after the project
The illustrative operator's biggest risk after the project is drift. New destination pages arrive with fresh photography straight from the camera, a marketing team adds a promotional banner that loads a new script, a booking vendor ships a release that reintroduces a keyboard trap, or a new upsell widget appears on the payment step. None of these looks like a performance or accessibility decision to the person making it.
A few habits keep the gains. Set a performance budget for destination and tour pages, such as a maximum image weight per page and a rule that third-party scripts load only where they are used, and check it when content is published. Keep a short standard for photography and video uploads. Rerun the core booking tasks with a keyboard and a mobile screen reader after every booking engine release. Review field data monthly, and weekly during booking peaks. And make the retest part of the vendor relationship, so that a provider's accessibility quality is discussed at contract renewal alongside price and features.
Most importantly, keep testing on the conditions your customers actually have: a mid-range phone, an unfamiliar network, a hurry and, for some of them, a screen reader, switch control or magnification. A booking path that works there works everywhere.
Related
Other work for travel and tourism
- UI & UX Design for Travel and tourism
- Photography & Product Visuals for Travel and tourism
- Video Editing & Production for Travel and tourism
- Motion Graphics & Animation for Travel and tourism
Performance & accessibility in other sectors
- Performance & Accessibility for HVAC and home services
- Performance & Accessibility for Staffing and recruiting
- Performance & Accessibility for Marketplaces and aggregators
- Performance & Accessibility for Media and publishing
More on performance & accessibility
- How the work runs, what it costs and how we check it
- WCAG 3 and What Comes Next, Done Properly
- Accessible Autocomplete Fields: What Actually Works
Trying us out
The quickest way to find out if we are any good for you is to send a couple of your own files and look at what comes back. It is free and there is no card involved. If the scope is already clear, ask for a fixed price instead.
