Dutch Hotel Website Accessibility: EAA Rules

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.

Not sure where your hotel website stands? Run a free accessibility scan to check for missing alt text, unlabelled form fields, keyboard traps and more. It takes about 60 seconds.

EAA Coverage for Hotels in the Netherlands

The Netherlands implemented the EAA as the Implementatiewet toegankelijkheidsvoorschriften producten en diensten (in force since 28 June 2025). Enforcement sits with the ACM (Autoriteit Consument & Markt). The ACM's grace period for self-reporting ended in October 2025. Active enforcement has been underway since then.

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. 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 actually 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 important accessibility area. A user who can't complete payment can't 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)

Accessibility Statement: a Netherlands-Specific Requirement

Hotels covered by the EAA are expected to publish an accessibility statement on their website. This document describes which parts of your site meet WCAG 2.1 AA, which parts don't (yet) and what your plan is. The Dutch government's accessibility resource DigiToegankelijk.nl explains the standard and provides templates used by public-sector organisations that private businesses can follow.

The statement doesn't need to be long. It needs to be honest. Guests with disabilities use it to decide whether to try your booking flow at all. A realistic statement that flags known gaps and gives a timeline is more useful than a generic claim of full compliance.

Put the statement in your footer. Link to it from your booking flow. And update it when you fix issues.

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. Structure it as HTML lists or tables, with alt text on any images.

Common Quick Wins for Hotel Websites

Dutch hotels are already on the ACM's radar. The ACM has explicitly targeted e-commerce booking flows in its early enforcement activity. The fixes below are exactly what ACM inspections look for.

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 a screen reader (NVDA + Chrome or Safari + VoiceOver on Mac)
• Test with real users with disabilities or hire accessibility specialists
• Publish an 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 and 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 ACM enforcement overview.

If you want a starting point before hiring a specialist, scan your hotel website for free. You'll see which accessibility issues are present and how serious they are, so you can prioritise your fixes.

---

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