Tour operator, travel agency and activity booking website accessibility: tour dates, itineraries and waivers

Tour operators, travel agencies and activity companies (boat trips, kayak rentals, walking and food tours, escape rooms, adventure parks) sell almost everything through one booking flow: pick a date and time, choose how many guests, add extras, sign a waiver and pay, often on a phone. Travellers with disabilities also need clear, honest details about what a tour involves before they book. If the booking calendar, guest stepper or waiver stops a keyboard, screen reader, magnifier or voice-control user, they book with someone else. Here's what to check.

1. Date and time pickers

Calendars that only work with a mouse, and dates shown as sold out only by greying them out, block keyboard and screen reader users. Let people move through dates with the keyboard or type a date, say in text which times are full or have few seats left, and announce the result when availability loads. (WCAG 2.1.1, WCAG 4.1.2, WCAG 1.4.1, WCAG 4.1.3)

<label for="tour-date">Tour date</label>
<input id="tour-date" name="tour_date" type="date" required>
<fieldset>
  <legend>Start time</legend>
  <label><input type="radio" name="time" value="09:00"> 9:00 am, 6 seats left</label>
  <label><input type="radio" name="time" value="13:00" disabled> 1:00 pm, sold out</label>
</fieldset>
<p role="status" aria-live="polite" id="avail"></p>
<!-- example values; after loading, put text such as "2 start times available on May 3" in #avail -->

Our 10-minute booking widget test covers third-party booking tools step by step.

2. Guest-count steppers and ticket types

Plus and minus buttons for "Adults", "Children" and "Seniors" often have no names, so a screen reader says "button, button". Name each button, show the count as text, and announce the new total and price. (WCAG 4.1.2, WCAG 4.1.3, WCAG 2.5.8)

<div role="group" aria-labelledby="adults-lbl">
  <span id="adults-lbl">Adults, $45 each</span>
  <button type="button" aria-label="Remove one adult">−</button>
  <span id="adults-count">2</span>
  <button type="button" aria-label="Add one adult">+</button>
</div>
<p role="status" aria-live="polite">2 adults. Total $90.</p>
<!-- example values -->

Make each button at least 24 by 24 CSS pixels so people with tremor can tap the right one.

3. Itineraries, prices and what's included as text

Day-by-day itineraries, price tables and "what's included" lists are often posted as a brochure PDF or an image. Put them on the page as headings, lists and tables so they can be read aloud, zoomed and translated. (WCAG 1.4.5, WCAG 1.3.1) See accessible tables for prices and hours and accessible PDFs.

4. Factual access details, not "fully accessible"

Travellers decide whether a tour works for them from specifics. Describe the experience factually: how far people walk and on what surface, steps or ladders, boarding a boat or vehicle, how long people stand, rest stops, toilets, whether a wheelchair or mobility aid can come along, service animals, and whether captions, transcripts or large-print materials are available. Don't call a tour "fully accessible" or "ADA compliant"; give the facts and a contact for questions. Example (made up for this guide): "Example: the walking tour covers about 1.5 miles on paved and cobbled streets with two short flights of steps; we stop every 20 minutes. Call or email us to discuss a step-free route." Put these details on the tour page itself, before the booking button.

5. Photos, maps and meeting points

Describe tour photos by what a traveller will actually see or do (alt="Example: small group kayaking past sea caves in calm water"). Write the meeting point, parking, drop-off and pickup instructions as text, not only as a map pin or a photo with an arrow, and include the address and a tel: phone link. (WCAG 1.1.1) See location pages and map embeds and our free alt text checker.

6. Waivers, guest details and checkout

Online waivers and guest forms are long and often time out. Give every field a visible label, use autocomplete for name, email, phone and birth date, group yes/no health questions with a fieldset and legend, write specific error messages, and don't make the lead booker type the same details again for each guest. Warn people before a held booking or waiver expires and let them extend it. A signature box that only works with a mouse or finger needs a typed-name alternative. (WCAG 3.3.2, WCAG 1.3.5, WCAG 3.3.1, WCAG 3.3.7, WCAG 2.2.1, WCAG 2.5.1)

<label for="sig">Type your full name to sign</label>
<input id="sig" name="signature_name" autocomplete="name" required aria-describedby="sig-hint">
<p id="sig-hint">Typing your name counts as your signature on this waiver.</p>

Check with your insurer or lawyer that a typed signature is acceptable for your waiver. See form error messages.

7. Video, slideshows and pop-ups

Caption tour videos and drone footage, don't auto-play sound, and give moving hero slideshows a pause button. "Book now, 10% off" and chat pop-ups must be reachable with the keyboard, close with Escape and not cover the booking button on a phone. (WCAG 1.2.2, WCAG 2.2.2, WCAG 2.4.3) See the pop-up and chat widget checklist and video captions.

8. Contrast and zoom

White text over sunny landscape photos is the most common contrast failure on tour sites. Add a solid or darkened background behind text and check at 200% zoom and on a narrow phone that prices and the booking button still fit. (WCAG 1.4.3, WCAG 1.4.10) Check colours with our free colour contrast checker.

Common mistakes

• A booking calendar that only works with a mouse, with sold-out dates shown only in grey.
• Guest-count plus and minus buttons with no names.
• The itinerary and prices only in a PDF brochure.
• "Fully accessible" or "ADA compliant" with no facts about walking, steps or boarding.
• A meeting point shown only as a map pin.
• A waiver that times out or needs a drawn signature.
• White text on bright landscape photos.

A 15-minute check you can do today

1. Using only Tab, Shift+Tab, arrow keys, Space and Enter, pick a tour, a date, a time and two guests, and reach checkout.
2. Check you can always see where focus is and close any pop-up with Escape.
3. Read one tour page and ask: could a wheelchair user or someone who can't stand for long decide from this text whether to book?
4. Leave a waiver field empty and read the error: does it say how to fix it?
5. Zoom to 200% on a laptop and check the price and booking button still fit.

Our keyboard test and screen reader test walk you through it.

Most tour companies use a booking platform; send that provider the questions to ask your web designer and ask what they'll fix in their widget. Avoid relying on an overlay widget instead of real fixes; see overlays vs real fixes.

What a scan can and can't check here

Our scan is automated, so it finds only part of the barriers on this page: missing alt text, unlabelled fields and buttons, low contrast and similar code problems on the pages it visits. It can't complete a booking, test a third-party calendar's keyboard behaviour, judge whether your access details are accurate, or reach waiver steps behind checkout, which is why the 15-minute check matters. Related: hotel and B&B websites, wedding and event venues, booking widgets.

This is general technical guidance, not legal advice, and it doesn't certify compliance with the ADA or any law.

Want the fixes written for you?

Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.

This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.

Related guides

• WCAG 2.2 explained for small-business websites
• Squarespace accessibility fixes: alt text, contrast, forms and more
• Wix accessibility fixes: a practical checklist
• WordPress accessibility fixes (block editor and themes)

All guides

This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.