Hotel Website Accessibility in the Netherlands: EAA and Booking Flow Requirements

Hotel websites have one of the most complex booking flows of any consumer-facing website. Room selection, date range pickers, guest count, add-on services, payment — each step is a potential accessibility barrier. The European Accessibility Act (Directive 2019/882) requires that the entire booking journey is accessible to users with disabilities.

EAA Coverage for Hotels

The EAA applies to hotel booking websites if the property:

• Is not a micro-enterprise (≥ 10 employees OR ≥ €2 million turnover)
• Offers online booking to consumers
• Is located in or serves the EU market

The hotel sector is explicitly mentioned in the EAA as an area where digital booking services must meet accessibility requirements. This includes:

• Direct booking websites
• Mobile booking apps
• Loyalty programme portals
• Guest service apps

Hotels that use third-party booking engines (Booking.com, Expedia) as their primary booking channel may have limited direct liability for those platforms' accessibility — but Booking.com and Expedia are themselves subject to the EAA and are required to comply. Your own direct booking website, however, is entirely your responsibility.

The Booking Flow: Specific Accessibility Requirements

Step 1: Date selection

Date range pickers — selecting check-in and check-out dates — are one of the most common accessibility failures on hotel websites. Standard calendar widget implementations are often inaccessible (failing WCAG 2.1 Success Criterion 2.1.1).

Problems:

• Calendar not reachable by keyboard
• Individual dates not announced by screen readers
• Unavailable dates not indicated to screen readers (often only shown in red)
• No text input alternative

Best practice:

• Offer both a calendar widget AND text input fields as alternatives
• Use ARIA to label the calendar: aria-label="Check-in date, use format DD/MM/YYYY"
• Mark unavailable dates with aria-disabled="true" and descriptive text
• Announce the selected date range after selection: "Check-in: 15 June, Check-out: 18 June" (3 nights)

Native input alternative:

<label for="checkin">Check-in date</label>
<input type="date" id="checkin" name="checkin" 
       min="2026-01-01" aria-required="true">

<label for="checkout">Check-out date</label>
<input type="date" id="checkout" name="checkout" 
       min="2026-01-02" aria-required="true">

Step 2: Room selection

Room cards with images, prices, and features must be accessible.

Room images: Every room photograph needs descriptive alt text. Avoid "Room 101" — describe what the image shows:

• alt="Standard double room with king-size bed, city view, and oak desk"
• alt="Bathroom with walk-in shower and marble countertops"

Room features: If features are communicated through icons (WiFi icon, pets allowed icon), they must have text alternatives.

Pricing: If a price changes based on a date selection or room option, the change must be announced to screen readers. Use aria-live="polite" on the price element.

"Select room" button: Every room's booking button must uniquely identify which room it selects. Not: <button>Book now</button>. Instead: <button>Book Standard Double Room (€180 per night)</button> — or use aria-label:

<button aria-label="Book Standard Double Room at €180 per night">
  Book now
</button>

Step 3: Guest count and special requests

Guest count selectors often use custom JavaScript controls (+/- buttons) that are not accessible.

The accessible approach:

<label for="guests">Number of guests</label>
<select id="guests" name="guests">
  <option value="1">1 guest</option>
  <option value="2">2 guests</option>
  <option value="3">3 guests</option>
  <option value="4">4 guests</option>
</select>

Or, if using custom + /- buttons, ensure they:

• Have ARIA labels: aria-label="Decrease guest count", aria-label="Increase guest count"
• Update an aria-live region when the count changes
• Can be reached and activated by keyboard

For special requests and accessibility needs (wheelchair accessible room, ground floor preference, assistance animal): mark these fields as optional and describe what your property can accommodate.

Step 4: Contact and payment information

This is the most critical accessibility area — a user who cannot complete payment cannot book. All form requirements apply:

• Every field has an associated visible label
• Required fields are indicated (not only by colour, but by text or asterisk with an explanation)
• Payment card fields have appropriate labels (use autocomplete attributes)
• Errors are announced programmatically after submission
• Success confirmation is announced to screen readers

<!-- Card number field with accessible label and autocomplete -->
<label for="card-number">Card number</label>
<input type="text" id="card-number" name="cardnumber" 
       autocomplete="cc-number" 
       inputmode="numeric"
       aria-describedby="card-number-help">
<div id="card-number-help" class="form-hint">Enter the 16-digit number on your card</div>

Step 5: Booking confirmation

The booking confirmation page must:

• Include all booking details in text format (dates, room type, total price, cancellation policy)
• Be printable without losing any information
• Offer email confirmation as an alternative for users who cannot read the confirmation page
• Be accessible to screen readers (structured headings, table for pricing breakdown)

Property Accessibility Information

The EAA governs digital accessibility of your website. A separate but related obligation: providing information about your property's physical accessibility.

Under the UN Convention on the Rights of Persons with Disabilities (ratified by the EU via Council Decision 2010/48/EC), hotels are increasingly expected to disclose physical accessibility features. Booking.com and other platforms now prompt hotels to complete accessibility profiles.

Best practice for your direct booking website:

• Include an "Accessibility" page or section describing physical features
• Use structured, list-based format (not just a paragraph)
• Cover: parking, entrance, lift/elevator, room features, bathroom, pool, restaurant

This information must itself be accessible — structured as HTML lists or tables, with any images having alt text.

Common Quick Wins for Hotel Websites

Under 1 hour each:

• Add alt text to all room and property images
• Add autocomplete attributes to checkout form fields
• Replace <img> icons with text labels for room features
• Add aria-label to "Book" buttons that uniquely identify each room

Under 1 day:

• Replace custom date picker with accessible native or ARIA-compliant widget
• Fix all colour contrast issues on text and buttons
• Add visible focus indicators throughout the booking flow
• Test the complete booking flow with keyboard navigation

Longer-term:

• Test with screen reader (NVDA + Chrome, or Safari + VoiceOver on Mac)
• Test with real users with disabilities or hire accessibility specialists
• Implement accessibility statement on your website

The Guest with a Disability Perspective

Think about a guest who is blind using a screen reader to book a room at your hotel. They need to:

1. Find your hotel (search, navigation — covered by general WCAG)
2. Select dates (date picker must be keyboard-accessible)
3. View available rooms (image alt text must describe the room)
4. Select a room and add-ons (buttons must be labelled, forms must have labels)
5. Enter payment details (form must be accessible)
6. Receive confirmation (confirmation must be readable)

If any step fails, the guest cannot complete the booking independently. Under the EAA, that is a violation.

For the complete EAA framework, see our EAA small business guide and EAA penalties overview.

---

This article is technical analysis, not legal advice. Consult a lawyer for advice specific to your situation.