Your QR Code Menu Is an Accessibility Lawsuit Waiting to Happen

Between 2020 and now, QR code menus went from a novelty to the default. You walk into a cafe, tap a sticker on the table, and a menu loads on your phone. No laminated card, no printed specials board, no staff-handled paper. From an operational standpoint, it is fantastic. From an accessibility standpoint, it is often a disaster.

If you run a restaurant, bar, cafe, hotel, food truck, or any hospitality business that uses QR code menus, there is a decent chance your setup quietly violates the Americans with Disabilities Act (ADA) in the United States and the European Accessibility Act (EAA) in Europe. Most owners do not realize this because the problems are invisible to sighted customers with working smartphones and good internet. The people who cannot use your menu usually leave without complaining. Some of them write to a lawyer.

This guide walks through every failure mode a QR code menu can have, why each one matters legally, and how to fix it without learning to code. No jargon. No DevTools. Just things you can test with a phone and reasonable patience.

Accessibility lawsuits against restaurants surged after 2019 for a couple of reasons. Courts in most U.S. circuits now accept that ADA Title III applies to websites used by public accommodations, not just physical premises. And QR code menus introduce a new failure pattern that plaintiffs’ lawyers have started explicitly naming in complaints: the menu is no longer part of the physical dining room, but a website that the customer is pushed toward as their only option.

When your server hands someone a paper menu, a visually impaired customer can ask for assistance or use a portable magnifier. When your server points at a QR code on the table, the customer is silently redirected to a web application that they have to use themselves. If the web application is inaccessible, they are stuck: either they reveal their disability to a stranger and ask for help, or they pay, tip, and leave without ordering what they wanted. Both outcomes have been cited in recent settlements.

The EAA, which came into force across the European Union in 2025, goes further. Any “digital interaction associated with consumer services” must meet WCAG 2.1 AA. A QR code menu in a Berlin hotel or a Madrid cafe falls squarely inside that definition. Enforcement is administrative rather than tort-driven, but the fines scale with turnover and are already being issued in the Netherlands, Germany, and Italy.

In short: the paper menu was a physical accommodation that the dining room staff could offer. The QR code menu is a digital service, and digital services have to be built accessibly.

The Seven Ways QR Code Menus Fail Accessibility

None of these require a developer to detect. You can test every one yourself with a phone and ten spare minutes per location.

1. The QR code itself is a sticker with no printed alternative

If the QR code is the only way to reach the menu, blind customers, customers who forgot their phone, and customers with low battery or no data plan cannot read the menu at all. This sounds like an edge case until you consider that smartphones fail more often than people admit and that the ADA explicitly covers customers who do not use your preferred technology.

Fix: Always offer a printed, large-print menu on request. Train staff to mention it proactively when they point at the QR code, not only when asked. Include a short URL printed on the table card so guests who cannot scan can still type the address into their browser. The URL should be short enough to type one-handed.

2. The URL the QR code points to is not a real menu — it is a PDF

This is the single most common failure. The QR code sends the customer to a scanned PDF of the menu, hosted on the restaurant’s website or on a third-party service. Scanned PDFs are images of text. Screen readers cannot read them. Zoom tools pixelate them. Customers on slow connections wait forever for them to load. They were never a web-friendly format, and a QR code is not a workaround.

Fix: Replace the PDF with real HTML content. Every modern menu platform — whether a restaurant-specific service, a Squarespace or WordPress page, or a Google My Business menu — can publish menus as searchable, zoomable, screen-reader-readable web pages. If you must keep a PDF for printing purposes, keep it as a downloadable extra, not the primary menu destination.

3. The menu page is built as a single image

A surprising number of menu pages are actually a single large image file (a JPG or PNG) with the entire menu rendered as graphics. They look fine on a phone, but they are functionally identical to a PDF: invisible to screen readers, unzoomable without pixelation, and completely useless to a blind customer.

Fix: If your menu page looks like a scan of a paper menu rather than normal web text, it is almost certainly an image. Ask your menu provider or web person to rebuild it as structured HTML: items and prices as text, categories as headings, and optional images only as photos that accompany the real text.

4. Text contrast is too low to read in bright lighting

Many menu designers love pale gray text on white backgrounds or gold text on cream. It looks elegant on a laptop in a dim office. In direct sunlight on an outdoor patio, it is illegible to almost everyone, and completely invisible to customers with low vision. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for body text and 3:1 for large text.

Fix: Use a free contrast checker (search “WebAIM contrast checker”) and paste in the foreground and background colors used on your menu. Aim for 7:1 rather than 4.5:1 if you can — it gives a margin of safety for reflective screens, small phone fonts, and aging customers.

5. Pinch-to-zoom is disabled

This one is almost always the menu platform’s fault rather than yours, and it is almost always unintentional. Many “mobile-optimized” menu templates include a viewport meta tag with user-scalable=no, which disables pinch-to-zoom on phones. Customers with low vision cannot enlarge the menu to read it, which fails WCAG 1.4.4 Resize Text. Apple and Google both technically override this setting, but not reliably across every browser and operating system version.

Fix: Ask your menu provider whether their mobile layout blocks zoom. If the answer is “yes, it keeps the design consistent,” push back. Zoom is a legal requirement, not a design preference. If they will not fix it, switch providers.

6. Dietary filters and ordering are not keyboard accessible

Modern menu platforms often include filters for vegetarian, gluten-free, nut-free, or halal items, plus an integrated ordering flow. Customers with motor impairments who cannot use a touchscreen and instead use a Bluetooth keyboard or a switch device need to be able to reach every filter, open every dropdown, and complete every order without ever touching the screen. Most menu platforms fail at this because they were built for touch first and keyboard as an afterthought.

Fix: Plug a Bluetooth keyboard into a phone or tablet and try to navigate your entire menu using only Tab, Shift+Tab, Enter, Space, and the arrow keys. If you cannot reach a filter, open a dropdown, or submit an order, neither can a customer who depends on a keyboard. Report the failure to your menu provider and escalate until they fix it.

7. Dynamic menu pricing, specials, and allergens are not announced

Screen readers read the page in source order. If your menu platform updates the “soup of the day” dynamically, or shows an allergen warning as a popup, or changes the price of a beer happy-hour-style, those updates are usually silent to assistive technology. A blind customer hears the original content, orders a soup that is no longer available, and then has an awkward conversation with the server. Worse, they may miss an allergen warning entirely.

Fix: Ask your menu provider whether their dynamic updates use ARIA live regions or equivalent mechanisms to announce changes to screen readers. If they cannot answer, or answer no, any time-sensitive or allergen-sensitive information needs to appear in the original page content, not as a dynamic overlay.

How to Test Your Own QR Menu in 10 Minutes

You do not need special tools. Here is a test protocol that any owner or manager can run at a single location in under ten minutes.

  1. Scan the QR code with your phone. Does it load a real web page (HTML menu) or a PDF/image? If PDF or image, stop here — you have a legal problem regardless of anything else.
  2. Turn on your phone’s screen reader. On iPhone, triple-click the side button with VoiceOver set up in Settings > Accessibility. On Android, enable TalkBack from Settings > Accessibility. Without looking at the screen, swipe right through the menu. Every item, price, and category should be announced clearly. If the screen reader says “image” or stays silent or reads nonsense, the menu is not accessible.
  3. Zoom in on the menu. Pinch-zoom the menu page. It should scale smoothly to at least 200% without cutting off content or forcing horizontal scrolling. If it refuses to zoom, or if text becomes pixelated, the site has disabled or broken zoom.
  4. Check contrast with a printout. Screenshot the menu and print it in black and white on a standard laser printer. If the grayscale output is legible, contrast is probably fine. If prices or ingredient lists disappear into the background, they will also fail for low-vision customers in normal lighting.
  5. Tab through the menu with a keyboard. Attach a Bluetooth keyboard to your phone or load the menu on a laptop. Press Tab repeatedly. You should be able to reach every link, filter, and form field. Every focused element should have a visible outline. If focus disappears or gets stuck in a loop, the keyboard experience is broken.
  6. Read the allergen and dietary information out loud. Can a customer with an allergy find the nut-free, gluten-free, or vegan items without tapping through a popup or chasing a moving banner? If not, the safety-critical information is not accessible.

Any of the six tests failing is a risk. Two or more failing is a legal problem that deserves a phone call to your menu provider this week.

Who Is Responsible: You or the Platform?

This is the question every owner eventually asks. Under the ADA, Title III responsibility attaches to the “public accommodation” — that is, you. It does not matter that you use a third-party menu platform. If the menu a customer cannot read was posted under your business name, you are the defendant in the lawsuit. The same is true for the EAA in Europe: the “service provider” is the restaurant, not the software vendor.

That said, your contract with the platform may let you pass some of the exposure on. Most menu platforms have accessibility commitments buried in their terms of service. Read yours, identify which WCAG level they promise, and make sure you can prove they are failing to deliver. In practice, the most common path is to change vendors, not to sue your vendor.

What a Good QR Menu Looks Like

A QR code menu that passes every check above is not hard to build. It looks like this:

  • The QR code points to a plain HTTPS URL at your own domain or a reputable menu provider’s domain.
  • The URL loads a real web page with text menu items, clear headings for categories, and no PDF download.
  • The menu is responsive (adjusts to phone, tablet, and laptop) without disabling zoom.
  • Color contrast passes a WCAG checker at every spot (item names, prices, allergen notes, call-to-action buttons).
  • Dietary filters work with a keyboard and are labeled so a screen reader announces them.
  • Dynamic content (specials, sold-out items) uses ARIA live regions or reloads into the static page, so updates are announced.
  • The menu page is tested at least quarterly with a screen reader and a keyboard.

None of this requires a custom build. Modern menu platforms — SpotOn, Toast, BentoBox, and several smaller regional providers — ship accessible defaults when you use their standard templates. If your provider does not, that is a reason to switch, not a reason to live with the risk.

Common Owner Mistakes When Trying to “Fix” Accessibility

Four patterns show up repeatedly in owner responses to accessibility complaints. All four make things worse.

Installing an accessibility overlay widget. Those little “accessibility button” widgets that promise to fix everything for $49 a month do not work, have been specifically cited in lawsuits as failing to provide WCAG compliance, and may actively break screen reader experiences that previously worked. Do not install them.

Adding a “contact us if you can’t use this menu” link. This shifts the burden onto the disabled customer and is explicitly rejected by courts as an ADA-compliant accommodation. The menu itself has to be usable.

Assuming “mobile-friendly” means accessible. Mobile-friendly is a design choice (layouts that work on small screens). Accessible is a functional requirement (usable with assistive technology). Many mobile-friendly menus are deeply inaccessible because their creators never tested with a screen reader.

Treating accessibility as a one-time fix. Menu platforms update constantly. A menu that was accessible in January may not be accessible in June if the platform pushed a new template. Test quarterly. Add it to your operational checklist the same way you add fire extinguisher inspections.

The Five-Minute Action Plan

If you own a restaurant or bar and you use QR code menus, do the following this week:

  1. Scan your own QR code and check whether it points to a real HTML menu or a PDF.
  2. If PDF, email your menu provider and ask them to publish an HTML version within thirty days.
  3. Regardless of format, run the ten-minute test protocol above at your busiest location.
  4. Print out a large-print paper menu as a backup. Train servers to mention it when seating guests.
  5. Put “quarterly menu accessibility test” on your operational calendar.

Every one of those steps is free, takes less than an hour, and demonstrably reduces legal exposure. An accessibility lawsuit settlement averages USD 20,000 to 75,000 for a small business, plus a mandatory site fix. A quarterly test costs you coffee.

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