Hotel Website Accessibility: Making Booking Work for Everyone

Hotel websites ask visitors to do more than just read. They need to pick dates, compare rooms, count guests, review prices and complete a payment. That's a lot of interactive steps. And every one of them can break for people using screen readers, keyboard navigation or other assistive technology.

The European Accessibility Act covers businesses that sell services online. If your hotel offers direct booking through your website, you're included. The deadline has passed and enforcement is underway.

The good news? Most hotel website accessibility problems follow the same patterns. Fix these and you'll handle the majority of issues your visitors face.

Date pickers are the biggest problem

The booking date picker is where most hotel websites fail. Custom calendar widgets that look beautiful on desktop often can't be operated with a keyboard at all. A visitor pressing Tab and arrow keys should be able to move between dates, select check-in and check-out, and confirm their choice. If they can't, the booking engine is broken for them.

What to check:

1. Put your mouse away. Try selecting dates using only your keyboard. Can you open the calendar? Move between months? Select a date? Close it?
2. Turn on a screen reader (VoiceOver on Mac, NVDA on Windows). Does it announce the selected date? Does it say which month you're viewing?
3. Check that the currently selected date has visible focus styling so sighted keyboard users can see where they are

If you built your own date picker, consider replacing it with a tested accessible component. If your booking engine provides the date picker, contact them about their accessibility compliance. They should be able to show you an accessibility statement or a VPAT.

Room selection needs more than pretty photos

Hotel websites love big photo galleries for each room type. Nothing wrong with that. But if the photos are the only way a visitor can tell rooms apart, you've got a problem.

Alt text on every property photo. Each image needs a description that tells the visitor what they'd see. "Deluxe double room with king bed, wooden floors and a balcony overlooking the garden" works. "Room photo" or an empty alt attribute doesn't. Visitors using screen readers rely entirely on this text to understand what they're booking.

Room descriptions in readable text. Many hotel sites display amenities as a row of icons: a tiny wifi symbol, a coffee cup, a snowflake for air conditioning. Without text labels on these icons, screen readers announce nothing or announce the image filename. Every icon needs a visible text label next to it or an accessible name that screen readers can pick up.

Clear room comparison. If you show multiple room types side by side, use a proper comparison layout where each room's name, price, size and included amenities are clearly structured. Don't rely on visitors being able to visually scan across columns to compare. Each room listing should make sense on its own.

Guest count selectors need keyboard support

Those plus-and-minus buttons for selecting the number of adults, children and rooms? They often fail for keyboard users. The buttons need to be focusable and operable with Enter or Space. They also need to announce the current count to screen readers when the value changes.

Test it: Tab to the guest count controls. Can you increase and decrease the numbers? Does your screen reader announce "2 adults" when you press the plus button? If the controls are built with <div> elements instead of real <button> elements, they probably won't work without extra ARIA attributes.

A simpler approach that works out of the box: use standard HTML number inputs or select dropdowns for guest counts. They're keyboard-accessible by default and screen readers already know how to handle them.

Pricing tables need proper markup

Hotels often display seasonal rates, room type comparisons or package pricing in tables. If those tables are built as images or as a grid of <div> elements styled to look like a table, screen readers can't make sense of them.

Use actual HTML <table> elements with proper <thead>, <th> and <td> tags. This lets screen readers announce the column and row headers as a visitor moves through cells. A visitor should be able to hear "Deluxe room, July, 189 euros per night" rather than just "189" with no context.

Don't show pricing only in images. If you have a beautifully designed rate card graphic, that's fine as a visual element, but the same information needs to exist as real text in the page.

Contact forms and special requests

Hotels get all kinds of requests through their forms. Early check-in, extra beds, dietary needs, accessibility requirements. The forms for these requests need to work properly.

Every field needs a label. A visible text label connected to the input through code. Placeholder text that disappears when you type doesn't count. Screen readers often skip placeholder text entirely.

Error messages need to be specific. "Please check your input" helps nobody. "Please enter a valid email address" tells the visitor exactly what to fix. Connect each error message to its field so screen readers announce the error when the visitor reaches that field.

Radio buttons and checkboxes need group labels. If you ask "What type of room do you prefer?" with radio button options below, the question needs to be coded as a fieldset legend so screen readers announce the question before reading out the options.

Mobile booking matters more than you think

More than half of hotel bookings start on a phone. Small screens make accessibility problems worse.

Touch targets need to be big enough. The recommended minimum is 44x44 pixels. Small "+" and "-" buttons for guest counts, tiny calendar dates and narrow form fields are hard to tap accurately. This affects everyone, not just people with motor disabilities.

Text needs to stay readable. Don't disable zoom on your mobile site. Some visitors need to enlarge text, and blocking pinch-to-zoom locks them out. Check that your booking flow doesn't overflow or break when text size is increased in the browser settings.

Forms should work in portrait mode. Some hotel booking flows only work properly in landscape orientation. Don't force an orientation. Let the visitor use their phone the way they're holding it.

Interactive maps and directions

Most hotel websites embed a map. That's helpful for many visitors but not for everyone.

Always provide your full address as plain text alongside the map. Include the street, city, postal code and country. Add brief text directions from the nearest train station or airport if that's relevant for your location.

This also solves the GDPR issue with Google Maps embeds. Load the map behind a consent click and show a static placeholder with the text address visible regardless. If your hotel also handles online bookings, keep the 14-day withdrawal right in mind, though hotel bookings with specific dates are typically exempt.

Third-party booking engines don't get you off the hook

Many hotels use booking widgets from their property management system or embed a Booking.com widget on their site. You might think "that's their responsibility, not mine." Partially true. The booking engine provider is responsible for their product's accessibility. But you're responsible for your website.

If you embed a widget that isn't accessible, your website isn't accessible. You chose to put it there. Before selecting a booking engine, ask the provider about their accessibility compliance. Check if they have a VPAT or accessibility statement. Test their widget yourself with a keyboard.

For the parts of your site outside the widget (your room descriptions, photos, contact forms, content pages) the responsibility is entirely yours.

Quick wins you can do today

You don't have to fix everything at once. Start with the changes that make the biggest difference. Our quick accessibility wins guide covers the fastest fixes across any website.

For hotels specifically, the highest-impact starting points are:

1. Add descriptive alt text to all room and property photos
2. Add text labels to every amenity icon
3. Put your full address in plain text next to your map embed
4. Test your booking form with keyboard-only navigation
5. Check that your date picker works without a mouse

Run a free accessibility scan on your hotel website to see where you stand. It checks for missing alt text, form label problems, keyboard traps and more. You'll get a clear picture of what needs attention first.

FAQ

Does the European Accessibility Act apply to small hotels?

Yes. The EAA applies to businesses that sell services online, regardless of size. If your hotel offers direct booking through your website, you're covered. Read our full EAA guide for the details on scope and timelines.

What if I use a third-party booking engine like Booking.com or Cloudbeds?

You're still responsible for the accessibility of your own website. The booking engine provider handles their widget, but everything around it (your content, navigation, photos, forms) is on you. Check that the widget you embed is accessible before committing to a provider.

Can I just add an accessibility overlay plugin instead of fixing these issues?

No. Overlay tools that promise one-line accessibility fixes don't actually work. They can't fix missing alt text, broken form labels or inaccessible date pickers. Some of them actually make things worse by interfering with screen readers. Fix the real issues in your code instead.

How do I test if my hotel website is accessible?

Start with keyboard testing. Put your mouse away and try to complete a booking using only Tab, Enter and arrow keys. Then scan your website for automated checks. For a thorough review, test with a screen reader (NVDA is free on Windows, VoiceOver is built into Mac). These three steps catch the majority of problems.

Are there accessibility requirements specific to the hospitality industry?

The EAA doesn't have hotel-specific rules. The same web accessibility standards (WCAG 2.1 level AA) apply to all websites. But hotels have particular risk areas because of complex booking interfaces, heavy photo usage and interactive elements like date pickers and guest selectors. The penalties for non-compliance apply equally across industries.