Restaurant Website Accessibility: Menu, Booking & Ordering

Restaurant websites have a particular accessibility problem. They rely heavily on menus, booking forms and ordering systems. These are exactly the features that break first for people using screen readers, keyboard navigation or other assistive technology.

The European Accessibility Act applies to businesses that sell products or services online. If your restaurant takes reservations or orders through your website, that includes you. The deadline has already passed. Enforcement is active, and penalties are real.

Here's the good news. Most restaurant accessibility problems follow predictable patterns. Fix these and you'll cover 80% of the issues.

PDF menus are the number one problem

This is the single biggest accessibility failure on restaurant websites. A PDF menu uploaded as a scanned image is completely invisible to screen readers. The visitor hears nothing. No dish names, no prices, no descriptions. Just silence.

Even PDFs that weren't scanned from paper are problematic. Most restaurant PDFs lack proper heading structure, reading order and tagged content. They're designed to look nice when printed, not to be read by software.

The fix is simple: put your menu in HTML on the page.

An HTML menu, the kind built directly into your webpage, works with every screen reader, every browser and every device. It scales properly on mobile. It loads faster than a PDF. And search engines can actually read it, which helps people find your restaurant.

How to structure an accessible HTML menu

• Use headings (h2, h3) for menu sections like Starters, Mains, Desserts
• Put each dish as a list item or in a structured layout with the name, description and price clearly separated
• Don't use images of text for dish names or prices
• If you offer allergen information, make it available as text, not as tiny icons without labels

If you absolutely must keep a PDF version for download, that's fine. But the HTML version should be the primary menu on your website. The PDF is a backup, not the default.

Booking forms need proper labels and error handling

Online reservation forms are standard on restaurant websites now. But many of them fail basic accessibility checks.

The most common problems:

Missing form labels. Every input field needs a visible label connected to it through code. Placeholder text inside the field doesn't count. When the visitor starts typing, the placeholder disappears and they can't remember what the field was for. Screen readers often can't read placeholder text at all.

No keyboard navigation. Some booking widgets can only be operated with a mouse. Date pickers are a frequent offender. If a visitor can't press Tab to move between fields and Enter to submit, the form is broken for keyboard users.

Unhelpful error messages. "Invalid input" tells nobody anything. If the phone number format is wrong, say "Please enter a phone number with 10 digits." If a required field is empty, say which field. And make sure the error message is linked to the field it belongs to so screen readers announce it.

What to check on your booking form:

1. Try filling out your entire booking form using only the keyboard. No mouse. Can you reach every field? Can you select a date? Can you submit?
2. Right-click on each form field, click Inspect, and look for a <label> element connected to the input
3. Submit the form with empty fields. Are the error messages specific and helpful?
4. If you use a third-party booking widget, check whether they publish an accessibility statement. Reputable providers like Formitable have been improving their accessibility

Online ordering systems need accessible carts

If you offer online ordering for delivery or pickup, the ordering flow has extra requirements. Visitors need to browse items, customize orders, review a cart and complete payment. Every step needs to work without a mouse and with a screen reader.

Accessible product listings. Each menu item in your ordering system should have a clear name, description and price that a screen reader can announce. If you use images of food, those need alt text describing the dish. "Golden-brown margherita pizza with fresh basil" tells a blind visitor what they're ordering. An empty alt attribute tells them nothing.

Form fields for customization. Toppings, portion sizes, special requests. These are often built as custom dropdown menus or clickable cards that don't work with keyboards. Standard HTML select elements and checkboxes work out of the box with assistive technology. Custom components need extra work to be accessible.

A readable cart. The order summary should list each item with its name, quantity, customizations and price. The total should be clearly announced. If a visitor can't review what they're about to pay for, that's a problem for everyone, not just people with disabilities.

Clear pricing throughout. Prices should be in actual text, not baked into images. Screen readers can read "12.50" but they can't read a styled image that shows the same number.

Google Maps needs a text alternative

Almost every restaurant website embeds Google Maps for the location. There are two problems with this.

First, the accessibility problem. Screen readers can't meaningfully interact with an embedded Google Map. A blind visitor can't find your address from the map widget.

Second, the GDPR problem. A standard Google Maps embed sends visitor data to Google before any consent is given.

Fix both at once: Add your full street address as plain text above or below the map embed. Include your city and postal code. This gives screen reader users the information they need and reduces your dependence on the map loading correctly.

For the GDPR side, load the map behind a consent click. Show a static image placeholder that becomes the interactive map after the visitor agrees.

Food photography needs alt text

Restaurant websites are visual. Beautiful photos of dishes are part of the experience. But every one of those images needs alt text that describes what's shown.

This isn't just for screen readers. Alt text appears when images fail to load on slow connections. It helps search engines understand your content. And it gives context to visitors who may not be able to see the image clearly.

Writing alt text for food photos:

• Describe the dish: "Grilled salmon fillet with roasted vegetables and lemon butter sauce"
• Mention the setting if relevant: "Outdoor dining terrace with string lights and wooden tables"
• Skip filler phrases like "image of" or "photo of." The screen reader already announces it as an image
• Keep it under 125 characters when possible

If the image is purely decorative, like a background pattern or a divider, use empty alt text (alt=""). But if it shows food, your space or your team, describe it.

Color contrast matters more than you think

Menu prices in light grey on a white background. Headings in a pale gold that matches your brand. Category labels in a muted pastel. These design choices make text hard to read for the 300 million people worldwide with low vision. They're also uncomfortable for anyone reading on a phone in bright sunlight.

WCAG 2.1 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Check yours at webaim.org/resources/contrastchecker.

Common restaurant website offenders:

• Prices displayed in a light font weight or color
• Navigation links that barely stand out from the background
• "Book now" buttons where the text doesn't contrast enough with the button color
• White text on food photography backgrounds without a dark overlay

You can often fix contrast issues by adjusting a single color value in your CSS. The design barely changes visually, but readability improves dramatically.

Mobile touch targets need to be big enough

More than half your visitors are on phones. And many of them are trying to book a table or order food while walking, on the bus or holding a coffee. Small tap targets make that frustrating for everyone. For visitors with motor disabilities, small targets make it impossible.

WCAG recommends touch targets of at least 44 by 44 pixels. That's roughly the size of a fingertip.

Check these on your mobile site:

• Menu navigation links and hamburger menu icon
• Date and time selectors in booking forms
• Plus and minus buttons for quantity in ordering systems
• "Add to cart" and "Remove" buttons
• Phone number and email links in the header or footer

If two tappable elements are too close together, visitors hit the wrong one. Add spacing between interactive elements on mobile.

Start with quick wins

You don't need to rebuild your website from scratch. Our guide to quick accessibility wins covers five changes you can make today without a developer. Start there if the list above feels overwhelming.

For restaurants specifically, the highest-impact changes are:

1. Replace your PDF menu with an HTML version on the page
2. Add alt text to all food photography
3. Add a text address next to your Google Maps embed
4. Test your booking form with only a keyboard

Those four fixes address the problems that affect the most visitors.

Check your restaurant website now

Not sure where your site stands? Run a free scan and you'll get a report showing accessibility, GDPR and security issues specific to your website. It takes 30 seconds.

For a deeper look at privacy rules that affect restaurants, read our GDPR guide for restaurant websites.

FAQ

Does the European Accessibility Act apply to my restaurant?

If your restaurant website offers online booking, ordering or any other commercial transaction, the EAA likely applies. The law covers businesses that provide services to consumers through digital channels. A simple brochure website with just your address and opening hours is less likely to fall under the rules, but the moment you add a booking form or ordering system, you're in scope. Read our full EAA guide for details.

Can I keep my PDF menu if I also have an HTML version?

Yes. Having both is fine. The key is that the HTML menu on your webpage is the primary version. A downloadable PDF can exist as an option for people who want to print it. Just make sure the PDF isn't the only way to see your menu. And if you can, make the PDF itself accessible too by using real text rather than a scanned image.

What if I use a third-party booking or ordering platform?

You're still responsible for accessibility on your own website. If the third-party widget they provide isn't accessible, that's your problem in the eyes of the law. Contact your provider and ask about their accessibility compliance. Many are working on improvements since the EAA deadline passed. If they can't give you a clear answer, consider switching to a provider that takes accessibility seriously.

How do I test my restaurant website for accessibility?

Start with two free tools. The WAVE browser extension (wave.webaim.org) gives you a visual overlay of accessibility problems on any page. Google Lighthouse, built into Chrome DevTools, includes an accessibility audit. For a broader check that also covers GDPR and security, scan your website here. Then try browsing your entire site using only your keyboard. If you get stuck anywhere, your visitors do too.