Restaurant Website ADA Compliance

Why restaurants are the #1 target for ADA lawsuits in 2025

Restaurants are now the single most targeted industry for ADA web accessibility lawsuits. In 2025, restaurants accounted for 34.65% of the 3,948 ADA web accessibility cases filed in federal court, more than any other sector and well ahead of fashion (25.96%), beauty (8.03%), furniture (7.67%), and health (7.17%). There are a few reasons this industry draws so much attention from plaintiff firms, and they all come down to the same thing: restaurant websites tend to have the same accessibility problems over and over.

The biggest one is the menu. Most restaurant websites display their menu as a PDF, often a scanned image of a printed menu. A screen reader looks at that PDF and sees nothing. No text, no structure, no way to tell a blind user what's on the menu or how much things cost. From an ADA standpoint, it's like posting your menu as a photograph on a blank wall with no braille alternative. The information is there for sighted users and completely absent for everyone else.

Then there's the shift to online ordering and reservations. The pandemic accelerated what was already happening: restaurants adding digital ordering systems, reservation widgets, and delivery integrations to their websites. Each of these adds interactive elements that need to be keyboard-accessible and screen-reader-compatible. Most aren't. And because these features involve core restaurant services (ordering food, booking a table), inaccessibility constitutes a barrier to the fundamental offering of the business.

Plaintiff attorneys have noticed the pattern. A handful of firms have built practices around restaurant ADA claims specifically. They run automated scans across restaurant websites, identify the ones with PDF menus and inaccessible ordering, and send demand letters. The volume makes it efficient. A firm can send 50 demand letters in a week targeting restaurant websites in New York, and a meaningful percentage will settle for $5,000 to $15,000 each.

The Domino's Pizza case changed everything

No discussion of restaurant web accessibility is complete without Robles v. Domino's Pizza (2019). Guillermo Robles, who is blind, sued Domino's because he couldn't use the company's website or mobile app to order pizza. He tried to order a custom pizza, apply a coupon, and find the nearest store. The site and app were incompatible with his screen reader.

Domino's fought the case aggressively. They argued that the ADA doesn't apply to websites because the DOJ hadn't issued specific web accessibility regulations. The case went to the Ninth Circuit Court of Appeals, which ruled against Domino's, holding that the ADA applies to the services of a place of public accommodation, including those provided via a website. Domino's petitioned the Supreme Court, which declined to hear the case, letting the Ninth Circuit ruling stand.

The Domino's case established binding precedent in the Ninth Circuit (which covers California, Oregon, Washington, Arizona, and several other western states) that restaurant websites must be accessible under the ADA. Other circuits have reached similar conclusions in their own cases. The practical effect is that there's no longer a serious legal argument that restaurant websites are exempt from ADA requirements.

The PDF menu problem

PDF menus are the single most cited accessibility issue in restaurant ADA cases. There are several levels of inaccessibility, and most restaurant PDFs hit the worst level.

Scanned image PDFs are the most common and the least accessible. The restaurant takes a photo or scan of their printed menu and saves it as a PDF. This contains no actual text data. A screen reader opens the file and announces "image" or nothing at all. The user has zero access to the menu content. This is the equivalent of hanging your menu on the wall and refusing to read it aloud to a blind customer.

Text-based PDFs without tags are slightly better. The PDF contains real text (you can select and copy it), but it lacks the structural tags that screen readers need to navigate. Without heading tags, the screen reader can't distinguish between section names ("Appetizers," "Entrees") and menu items. Without reading order tags, the screen reader might announce prices before item names, or jump between columns randomly. The user gets text but in a confusing, unusable order.

Tagged, accessible PDFs are the gold standard for PDF menus, but almost no restaurants produce them. These PDFs have proper heading structure, reading order, table formatting (for items and prices), and alt text for any images. Creating an accessible PDF requires either specialized software (Adobe Acrobat Pro) or expertise in PDF tagging. It's doable but labor-intensive, especially for menus that change frequently.

The real solution is simpler than fixing PDFs. Publish your menu as HTML text on your website. An HTML menu is inherently more accessible than any PDF because web browsers and screen readers are designed to handle HTML natively. Menu items as text, prices as text, section headings as actual headings. You can still offer a PDF download for customers who want to save or print the menu, but the web page should be the primary version.

Reservation system accessibility

If you take reservations through your website, that system needs to be accessible. The most common approach is embedding a third-party widget from OpenTable, Resy, Yelp Reservations, or a similar platform. These widgets vary significantly in their accessibility.

OpenTable's embedded widget has improved over the years, but restaurant implementations vary. The date picker, time selector, and party size controls all need to work with keyboard navigation. Some restaurant themes style these widgets in ways that break the underlying accessibility features. If you've customized the look of your reservation widget, test it with a keyboard to make sure it still works.

Resy and similar newer platforms have their own accessibility profiles. Request a VPAT (Voluntary Product Accessibility Template) from your reservation platform to understand their documented accessibility status. But remember: the VPAT covers the platform's default state. Your implementation, including custom styling and the surrounding page context, is your responsibility.

Some restaurants still use a simple contact form or phone number for reservations. A phone number is inherently accessible (screen readers can read it, users can call it), but if online booking offers a faster or more convenient experience for sighted users, providing only a phone number for blind users could be seen as unequal access. The safest approach is an accessible online form alongside a phone alternative.

Online ordering accessibility

Online ordering systems for restaurants are essentially simplified e-commerce platforms, and they carry many of the same accessibility issues. The menu browsing experience needs to work with screen readers. Menu item images (food photos) need alt text. Customization options (toppings, sides, sauces, cooking preferences) need to be keyboard-operable with proper labels. The cart needs to be navigable. Checkout forms need labeled fields and accessible error handling.

If you use a platform like ChowNow, Toast Online Ordering, or Square Online, the accessibility depends partly on the platform and partly on how you've configured it. Menu item descriptions and images are your content. The ordering flow interface is the platform's. When both have issues, the user gets an experience that's inaccessible from start to finish.

Many restaurants embed ordering widgets from these platforms using an iframe. Iframes create a separate document context that can be difficult for screen readers to navigate into and out of. If the iframe doesn't have a proper title attribute and the content inside isn't accessible, the entire ordering experience is broken for assistive technology users.

Real restaurant ADA lawsuits

Beyond Domino's, restaurant ADA web accessibility cases have hit businesses of every size.

Burger King, Pizza Hut, and other fast food chains have all faced ADA web accessibility complaints. These cases typically cite inaccessible online ordering, missing alt text on promotional images, and form fields without labels. Large chains usually resolve these through accessibility improvement programs rather than individual settlements, but the legal pressure and remediation costs are substantial.

Regional restaurant groups with 5 to 50 locations are frequent targets because they're big enough to have established web presences but often lack dedicated web accessibility resources. A restaurant group with 15 locations and an inaccessible website with PDF menus across all location pages creates a large attack surface for plaintiff attorneys.

Independent restaurants aren't immune. A single-location restaurant in New York received a demand letter over its inaccessible PDF menu and online ordering system. The settlement was $7,500 plus remediation costs. For a restaurant operating on thin margins, that's a meaningful hit. And the plaintiff's attorney identified the restaurant using automated scanning tools, meaning they didn't even need to physically visit the website to build their case.

The pattern in these cases is consistent. The plaintiff (or plaintiff's attorney) identifies a restaurant website with obvious accessibility violations, usually a PDF menu and inaccessible ordering. They send a demand letter citing specific WCAG violations. The restaurant either settles (most common) or faces a lawsuit. After settling, the restaurant must remediate the issues or face repeat claims.

How to fix your restaurant website

Convert your PDF menu to HTML

This is the single highest-impact change you can make. Take your menu content and publish it as text on a web page. Use proper headings for sections (Appetizers, Entrees, Desserts). List items with their descriptions and prices as text. If you have a long menu, consider a page per section or an accordion layout. Keep your PDF as a downloadable alternative, but make the HTML version the primary menu on your site.

Add alt text to food photos

Every image on your site needs alt text. For food photos, describe what's shown: "Grilled salmon with roasted vegetables and lemon butter sauce." For ambiance photos, describe the scene: "Outdoor patio dining area with string lights." For your logo, use your restaurant name as the alt text. Decorative images that don't convey information can use empty alt text (alt="") to tell screen readers to skip them.

Test your reservation and ordering systems

Put your mouse away and try to make a reservation using only your keyboard. Tab through the form. Can you select a date, time, and party size? Can you submit the form? Do the same with your online ordering. Can you browse the menu, select items, customize them, and check out without clicking anything? If not, those are the accessibility barriers that trigger demand letters.

Fix your contact and location information

Your address, phone number, and hours should be text on the page, not embedded in images. If you use Google Maps, make sure the iframe has a descriptive title attribute. Phone numbers should be actual links (tel: format) so mobile users and assistive technology can activate them. Hours of operation should be in a structured format, not a decorative image of a chalkboard.

Set up monitoring

Restaurant websites change regularly: seasonal menus, special events, holiday hours, new photos. Each update can introduce accessibility issues. A new menu PDF uploaded without alt text on the link. A special event page with images of the flyer but no text content. Ongoing monitoring catches these before they become demand letter material.

Frequently asked questions

Related tools: Home · ADA compliance checker · WCAG compliance checker · ADA compliance for ecommerce · ADA compliance for healthcare · ADA compliance for small business