Why restaurants keep showing up in accessibility claims

Restaurants update their websites constantly, rely heavily on photos, and often bolt on ordering and booking tools from several different vendors. That combination makes accessibility barriers common, and easy for anyone to spot.

The numbers reflect it. UsableNet's review of 2025 filings, published in January 2026, counted more than 5,000 digital accessibility lawsuits in the US last year, with e-commerce making up nearly 70% and food service roughly 21%. The same report found that a large share of federal cases were filed against companies that had already been sued before, which tells you that a quick fix after a first complaint often doesn't hold.

There is also a well-known court decision in this space. In Robles v. Domino's Pizza, the Ninth Circuit held in 2019 that the ADA applied to Domino's website and app because of their connection to its physical restaurants, and the US Supreme Court declined to review the case in October 2019. Courts in different parts of the country still disagree on some of the details, which is one more reason to get advice from a lawyer about your specific situation.

The US Department of Justice's guidance on web accessibility (March 2022) points businesses to the Web Content Accessibility Guidelines (WCAG) and lists exactly the kinds of barriers that are common on restaurant sites: missing alt text, poor color contrast, videos without captions and mouse-only navigation.

Menus: the page every guest opens

The menu is usually the most visited page on a restaurant site, and the most likely to be inaccessible. The three classic problems are:

• Menus as images. A photo of your printed menu is invisible to a screen reader and turns into a blur when someone zooms in on a phone.
• Menus as untagged PDFs. Most PDFs exported from design tools have no reading order, headings or text alternatives, so assistive technology reads them as a jumble or not at all.
• Prices and dietary icons that carry meaning only visually. A tiny leaf icon for "vegan" or a chili for "spicy" means nothing to a screen reader unless it has a text equivalent.

The fix is a real HTML menu page: section headings for starters, mains and desserts; each dish as text with its price; and dietary or allergen information written out (or icons with proper text labels). It is better for search engines too, which is why we recommend it even before accessibility comes up. We cover the business case in why PDF menus lose customers.

If you must keep a downloadable PDF for printing, keep it as a secondary option and make sure the HTML version has the same content and is updated at the same time.

Online ordering: where the money is

An ordering flow has more moving parts than any other page on your site: item options, quantity steppers, modals, a cart, a pickup or delivery time picker and a payment form. Each one can break for a keyboard or screen reader user. Common failures include:

• "Add to order" buttons built from plain div elements that can't be reached with the Tab key.
• Item pop-ups (modals) that don't move focus into the dialog, or trap the user inside with no way to close it.
• Options such as size, sides or spice level shown as styled boxes with no labels, so a screen reader announces "button, button, button".
• Cart updates that happen silently, with no announcement that an item was added.
• Time-slot pickers that only work with a mouse, and checkout fields that rely on placeholder text instead of real labels.
• Error messages shown only in red, with no text explaining what went wrong.

Many restaurants use a hosted ordering platform rather than custom code. That is fine, but it doesn't take the issue off your plate: your guest experiences it as your website. Ask the vendor for their accessibility documentation or conformance report, and test the flow yourself (see the checklist below). If you are choosing a platform now, put accessibility on the comparison list alongside fees. Our guide to commission-free online ordering explains the setup options.

Reservations and booking widgets

Reservation tools are usually embedded widgets from OpenTable, Resy, SevenRooms or similar providers. Before you embed one, check:

• Can you choose a date, party size and time using only the keyboard?
• Does the calendar announce dates properly to a screen reader, or is it a grid of unlabeled numbers?
• Does the widget have a meaningful title if it sits inside an iframe?
• Is there an obvious alternative, such as a phone number or email link right next to it, for anyone the widget fails?
• Do confirmation and error messages appear as text, not just a color change?

Also think about what guests need to know before they arrive: step-free access, accessible restrooms, space for wheelchairs, and whether you can accommodate service animals and allergies. A short, honest "Accessibility at our restaurant" section on your contact or FAQ page answers questions that people otherwise have to phone to ask.

A 20-minute restaurant accessibility check

You don't need special software to find the biggest problems. Work through this on your home page, menu, ordering flow and reservations page.

Automated tools help, but they only catch part of the picture. The WebAIM Million 2026 study found detectable WCAG failures on 95.9% of the top one million home pages, with low-contrast text (83.9%), missing alt text (53.1%) and missing form labels (51%) the most common, and WebAIM notes that automated testing understates the real number of barriers. For a deeper list, see our WCAG 2.2 AA checklist for small business websites.

A note on widgets that promise instant compliance

It is tempting to add a one-line accessibility toolbar and move on. Those tools don't fix the underlying code of your menu or ordering flow, and UsableNet's data shows lawsuits continue to be filed against sites that use them. We explain why in why accessibility overlays don't make your website compliant.

Keep it accessible as the menu changes

Restaurants change their sites more often than most businesses: weekly specials, seasonal menus, new photos, holiday hours, a new ordering partner. Every update is a chance for a new image without alt text or a new button that only works with a mouse. That is why we treat accessibility as an ongoing service rather than a one-off audit. Our website accessibility plans include monthly monitoring (Monitor, US$99/month), hands-on fixes (Care, US$249/month, or Care Plus, US$499/month), and a full audit from US$690 if you want a detailed starting point. No service can promise you will never receive a complaint, but steady, documented improvement makes your site work for more guests.

Frequently asked questions