How to Make Your Restaurant Website Accessible

If you own or manage a restaurant, your website is often the first impression a potential customer gets. They are checking your hours, browsing your menu, and deciding whether to book a table — all before they ever walk through your door. If any part of that experience is broken for someone with a disability, you have lost a customer before the conversation even started.

Restaurant websites have some of the most avoidable accessibility problems on the web. PDF menus that screen readers cannot read, online ordering forms that break without a mouse, reservation widgets with unlabeled fields — these are common, fixable, and increasingly a legal liability under both the Americans with Disabilities Act (ADA) and the European Accessibility Act (EAA).

This guide covers the most important fixes, in plain English, with no technical background required.

Why Restaurant Accessibility Matters

In the United States, courts have consistently ruled that ADA Title III applies to websites, including restaurant websites. Lawsuits have targeted chains and independent restaurants alike. Plaintiffs are typically blind or visually impaired users who cannot access a menu, find hours, or complete a reservation because the site is incompatible with screen reader software.

The European Accessibility Act (EAA), which came into full effect in June 2025, applies to any business selling goods or services to customers in the EU — including restaurants with online ordering or booking. If any part of your web presence serves European customers, EAA requirements apply.

The fix is not expensive. Most of the changes in this guide cost nothing but a bit of time.

The practical picture

Roughly one in five people has some form of disability. That includes blind and low-vision customers who use screen readers, deaf and hard-of-hearing customers, people with motor impairments who cannot use a mouse, and people with cognitive disabilities who benefit from clear, simple layouts. These are paying customers who want to eat at your restaurant. An inaccessible website turns them away before they arrive.

The Biggest Problem: PDF Menus

This one comes up constantly. A restaurant scans its printed menu, uploads it as a PDF, and calls it a day. The problem is that scanned PDFs are images — and images carry no text information that a screen reader can extract. A visually impaired customer who relies on a screen reader will hear nothing useful when they open that file.

Even a properly formatted PDF (not a scan) is a poor experience. PDFs are hard to navigate with keyboard-only controls, often display poorly on mobile, and cannot be resized the way regular web text can.

What to do instead

Create an HTML menu directly on your website. This means a real webpage with your dishes listed as text, organized with proper headings. Here is the basic structure:

  • Use a heading for each menu section (Starters, Mains, Desserts, Drinks).
  • List each item with its name, description, and price as text — not an image of text.
  • Include allergen information in text form next to each item, not buried in a separate download.

If you use a website builder like Squarespace, Wix, or WordPress, they all have page layouts that support this. You do not need to know how to code. Add a new page, call it “Menu,” and type your items directly into the editor.

You can still offer a PDF download for customers who want to print it. But the PDF should never be the only option.

Online Ordering Systems

Online ordering is where many restaurants lose accessibility ground, because the ordering system is usually a third-party widget embedded in the site. The restaurant owner did not build it and cannot directly control its code.

What you can control:

Ask your provider about accessibility. Contact your ordering platform (Toast, Square, Olo, Uber Eats embedded widgets, etc.) and ask them directly: “Is your online ordering system WCAG 2.1 AA compliant?” Reputable platforms will have an answer. If they do not, treat that as a red flag.

Test it yourself with keyboard navigation. Open your ordering page and put your mouse aside. Press Tab to move between items, Enter to select, and Escape to close dialogs. If you get stuck — if you cannot add an item to your cart, or if a popup appears that you cannot close — that is a keyboard trap and it needs to be reported to your platform.

Check that form fields are labeled. When entering your name, address, or payment details during checkout, each field should have a visible label above it (not just placeholder text inside the field that disappears when you start typing). Placeholder-only fields are a common accessibility failure.

Avoid ordering systems that require hovering. Some menu systems only reveal item descriptions or modifier options when you hover over them with a mouse. Customers navigating by keyboard or using a touch screen cannot hover. The information needs to be visible without hover interaction, or accessible through a clear tap or click action.

Hours, Location, and Contact Information

This seems basic, but it fails more often than you would expect.

Your hours and address should be on your website as real, readable text — not embedded in an image, not inside a non-interactive map widget, not locked inside a PDF. Screen readers can read text. They cannot reliably read text that has been embedded in an image.

Hours: List them in plain text. Monday-Friday 11am-10pm, Saturday 11am-11pm, Sunday 12pm-9pm. Simple, readable by any device.

Address: A text version of your address should appear on the page even if you also embed a Google Map. The map is fine as a supplement, but a customer using a screen reader or a low-bandwidth connection needs the text version.

Phone number: Make it a real, clickable telephone link (tel: links), not just text. This allows customers on mobile to tap and call directly. Most website builders handle this automatically, but check.

Contact forms: If you have a contact or booking inquiry form, every field needs a visible label. Describe clearly what you are asking for: Name, Email Address, Phone Number, Special Request. Do not rely on placeholder text alone.

Reservation Systems

OpenTable, Resy, and similar platforms handle most of the technical accessibility work, but you still need to check.

Test the booking flow. Go through the entire reservation process on your site using only a keyboard. Can you select a date? Choose a party size? Enter your information? Complete the booking? Do this test at least once after any platform update.

Check the embedded widget. When these platforms provide code to embed a booking widget directly on your site, the widget becomes part of your site’s accessibility responsibility. If it is broken, your customers experience the problem on your domain. Report issues to your reservation platform promptly.

Provide a fallback. If your online reservation system is down or inaccessible, customers need an alternative. Your phone number and email address should be easy to find — at the top of the page, or at a minimum clearly linked from your reservations page.

Confirmation emails. When a customer books a reservation, the confirmation email should include all booking details as readable text, not buried in an image.

Food Photos and Image Descriptions

Strong food photography sells. But every image on your site needs alternative text — a short description that a screen reader announces to blind users when it encounters the image.

Alt text for food is straightforward. Describe what is in the photo and make it relevant to a customer’s decision:

  • Instead of leaving the field blank, write: “Grilled salmon fillet on a bed of roasted vegetables with lemon butter sauce.”
  • For a photo of your dining room: “Warm, dimly lit dining room with wooden tables and exposed brick walls.”
  • For your logo: “The Elm Street Bistro logo.”
  • For purely decorative background images: use an empty alt attribute (alt="") so screen readers skip it.

Most website builders have an alt text field when you upload or insert an image. Fill it in every time.

One thing to avoid: do not use alt text to keyword-stuff or repeat your restaurant name. “Best restaurant downtown best food best service” is not useful alt text. Describe the image as you would describe it to someone on the phone.

If your menu or website is available in multiple languages, make sure the language is correctly declared for each version. This allows screen readers to switch pronunciation automatically. Most website builders and translation plugins handle this behind the scenes, but if you have manually created multilingual pages, check that the language is set correctly in the page settings.

Color and Contrast on Your Website

Restaurant websites often lean into mood: dark backgrounds, elegant fonts, muted palettes. These can look beautiful on a high-resolution display in a well-lit room. They can be completely unreadable for someone with low vision, or anyone reading in bright sunlight on a phone.

The requirement from WCAG (the Web Content Accessibility Guidelines that underpin both ADA case law and the EAA) is a contrast ratio of at least 4.5:1 between your text and its background. You do not need to memorize what that means. Use a free contrast checker tool: type in your text color and background color and it will tell you whether you pass or fail.

Common restaurant-website failures:

  • Light cream text on a white background.
  • Dark olive text on a dark wood-grain background.
  • Menu prices in a lighter color than dish names.

The fix is usually a small adjustment to your color settings in your website builder.

Mobile Accessibility

Most of your customers are looking up your restaurant on a phone. Mobile accessibility overlaps heavily with general mobile usability, but a few things specifically affect disabled users:

Touch targets need to be large enough. Buttons, links, and form fields should be easy to tap without needing pixel-perfect precision. If your website uses very small text links for your menu sections or reservation button, increase the tap area.

Zoom should not be disabled. Some websites prevent users from pinching to zoom. This is a direct accessibility barrier for low-vision users. Make sure your website builder settings do not block zoom (most modern builders leave it enabled by default, but check).

Text should reflow at large sizes. If a customer increases their phone’s text size in their accessibility settings, your content should rearrange rather than overlap or get cut off.

A Simple Checklist for Your Restaurant Website

Run through these items before you consider your site compliant:

  • Menu is published as HTML text, not only as a PDF or image.
  • Hours and address are readable text on the page, not just in an image or map embed.
  • Every image has meaningful alt text.
  • All form fields (contact, reservation, ordering) have visible text labels.
  • The site can be navigated using only a keyboard (Tab, Enter, Escape).
  • Text contrast is sufficient — dark text on light background, or the reverse.
  • Online ordering and reservation systems have been tested for keyboard accessibility.
  • Phone number is a clickable telephone link on mobile.
  • No critical information is only visible on hover.

What to Do When You Use a Third-Party Platform

Many restaurant owners use a single platform (like Toast, Square, or a reservation service) that handles their entire web presence. In that case:

  1. Check whether the platform publishes an accessibility conformance report (sometimes called a VPAT). If it does, read the summary section.
  2. File a support ticket asking specifically about WCAG 2.1 AA compliance.
  3. Document your request. If you are ever named in an ADA complaint, demonstrating that you actively asked your platform about accessibility and followed their guidance is relevant to your defense.
  4. Add a basic accessibility statement to your website. A short paragraph noting that you are committed to accessibility and providing a contact method for users who encounter barriers goes a long way — both legally and for customer trust.
  • EAA Compliance Checklist 2026 — If you serve European customers, this checklist covers what the European Accessibility Act requires and how to meet it.
  • Accessible Forms Guide — A deeper look at making contact forms, reservation forms, and online ordering fields work for everyone.
  • Alt Text Guide — Everything you need to know about writing effective image descriptions, with examples.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.