Hotel Website Accessibility in Belgium: Booking Flow Checklist

If your Bruges hotel, Antwerp boutique property, or Ardennes B&B takes direct bookings through its website, you're legally required to make the booking experience accessible. The European Accessibility Act (Directive 2019/882), implemented in Belgium through legislation transposing that directive, set a deadline of 28 June 2025. If you haven't audited your booking flow yet, now is the time.

The good news: you don't need to rebuild everything. You need to fix the parts that break the booking experience for visitors using keyboards, screen readers, or other accessibility tools. Most problems live in three places: date pickers, room selection, and payment forms. Let's walk through what to check and how to fix it.

The Date Picker Problem

Your booking engine's calendar widget is probably beautiful on a mouse. It fails catastrophically for keyboard and screen reader users.

Here's what broken looks like: a visitor using only their keyboard to navigate hits Tab to enter the check-in date field. The calendar pops up, but Tab no longer moves between months and dates—it skips past the entire calendar and lands somewhere else on the page. The visitor using a screen reader hears "clickable, calendar" with no sense of which dates are available or how to navigate forward to December.

What to test:

• Close your mouse. Only use Tab, arrow keys, and Enter to navigate the calendar.
• Can you move left/right to previous and next months?
• Can you move up/down through the weeks and days?
• Can you select a date and close the calendar by pressing Enter?
• If all three fail, your calendar needs rebuilding or replacing.

How to fix it: Most commercial booking engines (SiteMinder, Cubilis, Booking.com API integrations) have accessibility settings in their configuration. Look for "WCAG" or "keyboard navigation" in the admin panel. If the engine doesn't support it, you have three options: switch engines, use a third-party accessible date picker library (like Litepicker or Flatpickr with keyboard support), or limit guests to typing dates directly (DD/MM/YYYY format with clear instructions).

Your accessibility statement—which Belgian law requires you to publish—should list any known barriers. If your date picker has a workaround (like typing instead of clicking), document it there.

Room Selection: Photos and Amenities

Room photos need text descriptions. Not for SEO—for guests using screen readers.

What to write: Instead of relying on a photo thumbnail to show a room type, add alt text like "Superior double room with garden view, 28 square metres, wooden floors, en-suite bathroom." A screen reader user will hear this. A guest with low vision who zoomed in can read it.

Don't just describe the room type. Include what's actually visible: "Double bed with white linen, window overlooking courtyard, work desk, flat-screen TV, air conditioning." Concrete details help guests make decisions.

Amenity icons are a second problem. You probably have little icons: a bed icon for "double bed," a wifi icon for "free WiFi," a parking icon for parking. These icons are invisible to screen readers and meaningless without visual context.

Fix this:

• Add a text label next to every icon.
• If space is tight, use a tooltip or make the icon itself a button with a label. Screen reader users will hear it; sighted users see the label on hover or click.
• Never rely on color alone to distinguish room types. If you use a green box to mean "available" and a red box to mean "booked," add text: "Available" and "Booked."

Room Count and Guest Count Selectors

Your + and − buttons need accessible names.

The broken version: a screen reader user lands on a + button with no label. They press it, the room count goes up, but the screen reader says nothing. The guest doesn't know what happened.

The fixed version: the + button is labeled "+ More rooms" and announces "2 rooms selected" after the click. The input field shows the number. The screen reader announces updates when the value changes.

Here's how:

• Give the + and − buttons proper labels using aria-label or visible text inside the button (e.g., "+ Add room").
• The input field itself needs a visible label: "How many rooms?" not a placeholder that disappears when you click.
• Update the announced value when the count changes using aria-live="polite" so screen reader users hear it.

The same logic applies to adult and child counts. Each selector needs a clear label, functioning + and − buttons, and announced updates.

Payment Step: Labels and Error Messages

Card details fields need visible labels, not placeholder text that vanishes.

The wrong approach:

[John Smith________] ← placeholder text says "Cardholder name"

Once the guest starts typing, the placeholder disappears and they forget what the field is for.

The right approach:

Cardholder name
[John Smith________]

The label stays visible. The field remains clearly marked.

Apply this to every payment field: cardholder name, card number, expiry, security code, billing address.

Error messages must be specific and linked. If a guest enters an invalid card number, don't show a generic "Payment failed" at the top of the page. Tell them exactly which field has the problem: "Card number is invalid. The number must be 16 digits for Visa or Mastercard." Link the error message to the card number field using aria-describedby so screen reader users know which field to fix.

Accessibility Statement: A Legal Requirement

Belgian law (via the transposition of Directive 2019/882) requires you to publish an accessibility statement on your website. This must include:

• Your commitment to accessibility and WCAG 2.1 Level AA as your target standard.
• Known barriers or limitations (e.g., "Our calendar widget requires mouse use; guests can type dates instead").
• How to report barriers you missed: an email address or contact form.
• A link to the Belgian DPA (Autoriteit Bescherming Persoonsgegevens / Autorité de Protection des Données) if a guest wants to file a complaint.

Many hotels worry this statement is an admission of guilt. It's not—it's transparency. It shows you take accessibility seriously, you've audited your site, and you're fixing problems as you find them.

Language Versions: Both Dutch and French

If your website serves Dutch and French speakers—which most Belgian hotels do—accessibility requirements apply to every language version.

Check your Dutch booking page and your French booking page separately. Calendar navigation, room selection, payment fields must all work in both. This doubles your testing work but protects your entire guest base.

Practical Checklist for Your Hotel

• Test your date picker with keyboard only (Tab, arrow keys, Enter). If it fails, contact your booking engine provider or switch to an accessible alternative.
• Add descriptive alt text to every room photo. Include room type, size, furnishings, and view.
• Label every amenity icon with text, not just the visual icon.
• Test room count and guest count selectors with a screen reader. Verify that updates are announced.
• Replace placeholder-only labels with visible labels on payment fields.
• Make error messages specific and link them to the fields they describe.
• Publish an accessibility statement listing known barriers and your contact for reports.
• Audit both your Dutch and French booking pages.
• Test with a free screen reader (NVDA for Windows, built-in VoiceOver on Mac).

What Enforcement Looks Like

The FOD Economie (Federal Public Service Economy) enforces accessibility in Belgium. They can investigate complaints, require you to fix barriers, and in serious cases, issue fines. Most hotels won't face an investigation overnight—enforcement is complaint-driven. But a guest with a disability who can't complete a booking has grounds to complain.

More likely, you'll see the impact in lost bookings. A guest using a screen reader or keyboard-only controls will abandon your booking flow if it doesn't work. They'll book elsewhere. Accessibility isn't a compliance checkbox—it's a revenue protection measure.

Start with your date picker and payment form. Those are the friction points. Test them yourself with keyboard and screen reader. If they fail, you've found your first priority. Fix the date picker, and you've solved the biggest problem most accessible hotels face.

Your guests with disabilities aren't asking for anything special. They're asking for the same smooth booking experience your sighted, mouse-using guests expect. Making that work is your legal requirement and your business interest.