Belgian Hotel Accessibility: 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) was transposed into Belgian law through the Wet van 5 november 2023, which amends the Code of Economic Law to incorporate accessibility requirements for digital services. The enforcement deadline was 28 June 2025. If you haven't audited your booking flow yet, you're already past the deadline.

Not sure where your site stands? You can run a free scan on TrustYourWebsite to spot the most common accessibility and compliance gaps in your booking flow before a guest or regulator does.

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 contact route for guests who want to escalate unresolved barriers to a regulator or equality body.

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. See our accessibility statement template for a ready-to-use version you can adapt.

Language Versions: Dutch, French and German

If your website serves Dutch and French speakers (which most Belgian hotels do), accessibility requirements apply to every language version. Hotels in the German-speaking community of eastern Belgium need to check their German pages too.

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. The language split is also a practical consideration for your accessibility statement: publish it in every language your site serves, not just one.

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).

Who Enforces This in Belgium

Two bodies matter here.

The FOD Economie (Federal Public Service Economy, also known as SPF Economie) is the primary enforcement authority under the Belgian EAA transposition. They can open investigations into complaints, order you to fix barriers and sanction businesses that don't comply. Enforcement is complaint-driven, not proactive audit-based. That matters: if a guest with a disability can't complete a booking on your site, they have grounds to file a formal complaint.

UNIA is Belgium's independent equality body. They handle discrimination complaints based on disability, including situations where a digital barrier prevents someone from accessing a service. UNIA doesn't set accessibility standards, but they can intervene when inaccessible websites effectively exclude guests. Hotels are explicitly within their remit alongside restaurants and other hospitality businesses.

If you want to go beyond baseline compliance, AnySurfer is the Belgian accessibility label for websites. It's awarded after an independent audit against WCAG criteria. It won't replace your legal obligation, but it signals to guests and partners that your site has been independently verified.

More likely than a formal investigation, 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.

For a broader look at how the EAA applies to Belgian businesses beyond hotels, the EAA small business guide covers the full scope of services affected and what compliance looks like in practice.

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 hotels face.

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