Teardown Published

Common QR menu mistakes I see at restaurants in 2026 (with fixes)

A teardown of seven recurring QR menu failure modes — PDF-only, illegible text, missing tap-to-call, baked-in phone numbers, no print stylesheet — based on first-party workflow tests against 5 independent restaurant menus.

Primary intent: qr menu mistakes 2026 Sources: S-001,S-002,S-005,S-008,S-015,S-301,S-302,S-304,S-305

This is a teardown post. We picked five real independent restaurant QR menus in May 2026 (NYC, Boston, Berkeley, Lisbon, Berlin — kept anonymous because the point is the failure mode, not the specific restaurant). We ran each through the 10-row mobile audit. Below: the seven mistakes that came up most often, with the specific fix.

TLDR

The seven mistakes, in frequency order: PDF as the destination (4/5), no tel: link (5/5), allergen icons with no alt text (5/5 of those that had any allergen icon at all), no print stylesheet (5/5), illegible body text on default zoom (4/5), no individual item URLs (5/5), phone number baked into an image (3/5). Each has a fix that takes under an hour.

Mistake 1 — The QR sticker routes to a PDF

Frequency in sample: 4/5 (S-301).

Why it happens: The owner already had a PDF menu from a designer. The cheapest path to “having a QR menu” was to upload that PDF to Google Drive and put the share link behind the QR. Done in 10 minutes; broken on mobile from minute one.

Diner-facing symptom: “Showing me an 8.5-by-11 inch PDF menu on my phone screen is not the solution” (S-001).

Fix: convert the PDF to an HTML page. Step-by-step in the weekend conversion guide. The minimum viable HTML menu is a single ~3KB file.

Mistake 2 — Body text is unreadable at default zoom

Frequency: 4/5 (S-301).

Why it happens: PDFs are sized for paper. A 10pt Garamond paragraph on letter paper is readable at arm’s length. The same PDF rendered on a 375px-wide iPhone renders that paragraph at about 8px. WCAG 2.2 SC 1.4.4 (Resize Text) requires content to scale to 200% without loss, which PDFs don’t (S-008).

Diner-facing symptom: Pinch-and-zoom every section.

Fix: in HTML, set body to 17px or larger, line-height 1.5+. Test on the actual phone, not just the desktop emulator.

Frequency: 5/5 (S-302).

Why it happens: The phone number is part of the menu design that the print-designer laid out. It got rendered into the PDF or the menu image. No one converted it to a <a href="tel:...">.

Diner-facing symptom: Diner copies the number manually or asks the server.

Fix: add a sticky or repeating header strip with the phone number as <a href="tel:+15551234567">555-123-4567</a>. Restaurants that take phone reservations see real calls from this.

Mistake 4 — Allergen icons have no alt text

Frequency: 5/5 of the menus that had any allergen icons at all (S-304). Most had no allergen labelling, period.

Why it happens: Allergen icons came from the same PDF-style design tools. Even when exported as separate images, no one wrote alt text.

Diner-facing symptom: Screen reader users get nothing. Sighted users get either no allergen info or icons that look like a peanut but might mean something else.

Fix: see the allergen labelling post. Use <img alt="contains peanuts">. Add a legend.

Mistake 5 — No print stylesheet

Frequency: 5/5 (S-305).

Why it happens: The owner has been maintaining a separate Word doc for kitchen prep. The QR menu and the kitchen menu drift apart over time.

Diner-facing symptom: None directly. Owner-facing: the kitchen runs on yesterday’s prices when a server prints today’s.

Fix: add @media print { ... } CSS. Hide header/footer, white background, two-column layout with prices on the right. Print one copy, hand it to the kitchen.

Mistake 6 — The phone number is baked into an image

Frequency: 3/5 (S-302).

Why it happens: Same designer pipeline that baked the menu into a PDF baked the contact info into the header image.

Diner-facing symptom: Can’t tap, can’t copy easily, can’t translate. Screen readers see “image”.

Fix: every piece of text needs to be text. Use real HTML for headers and contact info. Use images only for decorative elements that have a separate text equivalent.

Mistake 7 — Items can’t be linked individually

Frequency: 5/5 (PDFs by definition).

Why it happens: PDFs are flat — no id attributes, no URL fragments.

Diner-facing symptom: Nothing severe, but it limits social sharing (“check out the bucatini at [link]”) and prevents Google from indexing individual items.

Fix: in HTML, give each item an id (slugified item name). Now /menu#bucatini-cacio-e-pepe works.

The fix-priority order

If you can only fix one thing this week: mistake 1 (drop the PDF).

If you can fix three: 1, 2 (body text), 4 (allergen alt text).

If you can fix all seven: see the weekend conversion guide for the whole flow.

Common mistakes (the meta level)

  • Treating the QR menu as a design problem. It’s an engineering + accessibility problem first; design comes second.
  • Hiring a designer who only ships PDFs. Push back — ask for the HTML. Many independent restaurant designers in 2026 can ship a static HTML menu if asked.
  • Putting the menu inside a Wix or Squarespace “Smart Section” PDF widget. It’s still a PDF; you’ve just added a wrapper.
  • A/B-testing your QR menu. You don’t have the volume. Just pick the good version (HTML, 17px+ text, allergen alt text, tel: link, print stylesheet) and ship it.

FAQ

How big was your sample, exactly?

Five restaurants in May 2026, across three countries, all independent (one to three locations each). Small sample — we say so explicitly. The patterns are common enough that we’d be surprised if a 50-restaurant sample produced a wildly different ordering.

Why don’t you name the restaurants?

The point is the failure mode, which is independent of who’s making it. Naming them turns this from “tear down the pattern” into “publicly shame these specific people”.

Is this a “vendor blog” complaining about competitors?

We’re a coming-soon project, not a vendor with revenue. We are critical of the PDF-as-menu pattern, not of any specific vendor — including MenuTiger, Menubly, and Toast, all of whom solve some of these issues out of the box.

Doesn’t Google care about Core Web Vitals?

Yes, since 2021’s Page Experience update (S-015, S-016). A PDF-based menu tanks LCP and FID/INP. An HTML page that follows the audit sails through.

Will mistake 1 stop happening once everyone moves off PDFs?

We hope so. Until then, the audit is useful as a self-check.


The 10-row audit maps each mistake to a row. The weekend conversion guide is the fix.