Why Restaurant and Hotel Websites Get Sued So Often
ClearPath Team · 2026-08-03 · 7 min read

If you run a restaurant, cafe, or small hotel, you're a bigger litigation target than most e-commerce brands realize. In 2025, restaurants and food and beverage businesses accounted for more ADA website lawsuits than any other industry, and hospitality overall made up a large share of the rest. That's not an accident of bad luck. It's because the three pages every restaurant and hotel site has in common happen to be some of the easiest accessibility failures for a plaintiff's tester to document in about five minutes.
The most-sued sector, and why it's an easy target
In 2025, Restaurants, Food, Drinks and Beverages was the most targeted industry, accounting for 1,368 lawsuits, likely reflecting the sector's heavy reliance on high-traffic, time-sensitive digital experiences such as online menus, ordering and reservations, and location finders, where accessibility failures in navigation, forms, modals, and other interactive components frequently create barriers and trigger complaints. Hotels and broader hospitality add to that number, with restaurants, hotels, and food service businesses being the second most targeted sector in ADA web litigation, with issues often affecting digital ordering, hotel booking and menu systems that lack basic accessibility features.
This isn't random. Serial plaintiffs and their attorneys focus on online menus, ordering and reservations, and location finders because failures there are easy to reproduce and document. A tester doesn't need to dig through your whole site. They open your menu page, try to book a table with a screen reader or keyboard only, and take screenshots of exactly where it breaks. That's the whole case.
The four failures that show up over and over
1. The PDF menu. A menu built as a PDF, especially one exported from a design program, is often just an image with no underlying text layer. A screen reader user gets nothing: no dish names, no prices, no allergen notes. Even a "real" text-based PDF usually has no heading structure and no reading order, so a screen reader jumps around the page in a confusing sequence.
2. The scanned or photographed menu image. Some restaurants skip the PDF and just post a photo of the printed menu, sometimes from a phone. There's no text at all for assistive technology to read. This is arguably the single most literal accessibility failure a tester can point to, because there's nothing to defend. The content simply doesn't exist for a non-sighted visitor. Worth noting: a widget like ClearPath can adjust text size, spacing, and contrast for visitors reading the rest of your site, but it cannot conjure text out of a flat image, so a photographed menu still needs to be rebuilt as real text somewhere on the page.
3. The date picker that traps the keyboard. Reservation and booking widgets almost always include a calendar for picking a date. Date pickers and other complex form components frequently create keyboard traps, capturing all keyboard events rather than just the keys needed for their functionality, so a keyboard user who opens the calendar may be unable to exit using the standard Tab or Escape keys. For someone who can't use a mouse, that's not an inconvenience, it's a dead end. They literally cannot finish booking a table or a room. Custom JavaScript datepicker controls are almost always inaccessible to keyboard and screen reader users, which is exactly why third-party reservation widgets show up in demand letters so often.
4. The unlabeled reservation or ordering form. Party size, time, phone number, special requests fields that look fine visually but have no programmatic label attached. A sighted user sees the placeholder text and fills it in without thinking. A screen reader user tabs into a field and hears nothing useful, no idea what to type or why the form rejected their submission.
Why courts don't care that you're small
Restaurant owners often assume lawsuits target big chains. They don't, mostly. In Herrera v. Grove Bay Hospitality Group, a Florida court found that a restaurant could not pass ADA liability to its website vendor. Using a third-party ordering platform or booking widget doesn't shield you if that vendor's tool is inaccessible. And the Ninth Circuit's ruling in Robles v. Domino's created binding precedent that restaurant websites must be accessible regardless of chain size, and independent restaurants are covered by the same rule.
What to do first if you have no developer
You don't need to rebuild your site. Start with the cheapest, highest-impact fixes:
- Replace the PDF or image menu with real HTML text. Even a simple page listing dishes, descriptions, and prices as regular text is a massive improvement over a scanned image. This is a copy-and-paste job, not a redesign.
- Test your reservation flow with just a keyboard. Unplug your mouse and try to book a table using only Tab, Enter, and arrow keys. If you get stuck anywhere, that's your demand-letter risk, and it usually points straight at the date picker.
- Ask your booking or ordering vendor directly whether their widget is WCAG 2.1 AA tested. If they can't answer, that's a real answer.
- Get a real audit before you spend money on fixes. A scan alone misses most issues; a proper audit combines automated and manual testing so you know what's actually broken.
If you're also looking for a quick way to make the rest of your site, your about page, your location info, your contact form, more usable while you handle these bigger structural fixes, installing something like ClearPath is a one-line add that gives visitors 25 adjustment tools across 8 preset profiles in 14 languages, plus an auto-generated accessibility statement. It's a reasonable step alongside the fixes above, not instead of them.
What it actually costs
For a typical small restaurant or hotel site (5 to 20 pages with a menu, ordering, and reservation feature), realistic numbers look like this: a typical small business with a 10-50 page site should expect $5,000 to $25,000 in year one for audit plus remediation, and $2,000 to $5,000 annually for monitoring and maintenance. Smaller, simpler sites can land at the low end of that. Eligible small businesses can recover up to $5,000 through the IRS Disabled Access Credit on Form 8826, which covers 50% of eligible expenses between $250 and $10,250. Compare that to a settlement: demand letter settlements typically range from $1,000 to $25,000, and out-of-court settlements average around $30,000 but can reach $150,000. Fixing it first is almost always cheaper than fighting it later, and it's a one-time project cost, not a forever bill.
Where ClearPath fits
Be clear-eyed about what a widget can and can't do here. A scanned menu image with no text layer, a PDF menu with no reading order, and a keyboard-trapping date picker inside your reservation widget are code-level and vendor-level problems. Those need to be fixed at the source, either by rebuilding the menu as real HTML or asking your booking vendor to fix their calendar, or by switching to a vendor whose widget actually works with a keyboard. ClearPath does not write alt text, add form labels, fix keyboard traps, or touch a PDF. What ClearPath does handle is the visitor-facing layer on top of your existing site: one line of code adds 25 adjustment tools covering text sizing, contrast, spacing, and reading supports across 8 profiles built for specific needs like low vision or motor impairments, in 14 languages, plus an auto-generated accessibility statement so your restaurant or hotel has a public record of the commitment. That helps visitors who are already on your site adjust it to their needs and supports your broader WCAG 2.2 goals, but it doesn't replace fixing the menu, the date picker, or the form labels themselves. Both pieces matter, and neither one covers for the other.
Not sure how many of these issues are on your own site? Run a free scan, see what comes up, then switch on the tools that help your visitors today.
The bottom line
Restaurants and hotels get sued over their websites more than almost anyone else because the failures are so easy to prove. A missing text layer on a menu, a calendar that won't let go of the keyboard, a form field with no name attached: these aren't subtle bugs. They're the first three things a tester checks. Fix the menu, test the booking flow with a keyboard, and ask hard questions of whatever vendor runs your reservations or online ordering. That's where the real risk lives, and it's fixable without a full site rebuild.