Open Your Menu PDF With Your Eyes Closed
A screen reader user visits your restaurant's website tonight, taps "Menu," and hears nothing. No dish names. No prices. No section headers. Just silence, followed by a file that assistive technology can't make sense of at all.
That's not a bug in their screen reader. That's what happens when a menu is published as a scanned image wrapped in a PDF — and it is, by a wide margin, one of the single most common accessibility failures in the entire restaurant industry.
The Scenario Every Restaurant Owner Recognizes
Picture a restaurant owner who just paid a designer for a beautiful new menu. Elegant typography, a nice paper stock, maybe a subtle logo watermark. It gets printed, it gets photographed or scanned, and it gets exported straight to PDF and uploaded to the website.
Visually, it's perfect. To a sighted visitor, nothing looks wrong at all.
But that PDF is really just a picture of text — a photograph, functionally, no different than a JPEG of the menu taped to the front window. There is no actual text underneath it for a screen reader to grab onto. No dish names, no descriptions, no prices exist as text anywhere in that file. A screen reader can't read a picture. It can only read text, and there isn't any.
So a blind guest — someone deciding whether to order dinner from your restaurant tonight — gets nothing. Not a garbled version of the menu. Not a partial menu. Nothing. They either call the restaurant and ask someone to read the whole thing aloud, or they go somewhere else that made it easy.
Why This Keeps Happening
Nobody sets out to lock anyone out. It happens because "export to PDF" feels like the finish line. The menu looks done. It's on the site. Nobody in the workflow ever opens it with a screen reader to check, because why would they — it looks completely normal.
That's exactly the trap. A PDF that renders visually perfect and a PDF that's completely unusable by assistive technology can look, to the naked eye, identical. The failure is invisible unless you go looking for it.
The Fix: A Real HTML Menu, Not Just a Prettier PDF
The good news is this isn't a hard problem to solve — it's just an overlooked one. The fix isn't "never use a PDF again." It's making sure there's an accessible way to get the same information.
The strongest option, and the one we recommend starting with, is a real HTML menu page built with actual text and proper heading structure — under 1.3.1 Info and Relationships, section names like "Appetizers," "Entrées," and "Desserts" should be marked up as real headings, not just bold text that looks like a heading. That structure is what lets a screen reader user jump straight to "Desserts" the same way a sighted guest's eye jumps down the printed page — instead of being forced to listen through the entire menu top to bottom every single time.
If a PDF still needs to exist — for a printable version, say, or because a corporate brand team insists on it — it needs to be built from real, selectable, taggable text rather than a scanned image. That's the same remediation approach we cover in depth in our accessible PDFs guide: proper tags, a logical reading order, and real text a screen reader can actually parse. A tagged, text-based PDF and a scanned-image PDF can look pixel-for-pixel identical to a sighted visitor and be worlds apart to everyone else.
Practically, for most restaurant sites the highest-leverage move is this: HTML menu first, PDF second. It's usually the fastest fix to ship, and it's the one guests actually interact with most.
The Stat: WebAIM's annual "WebAIM Million" evaluation of the top 1,000,000 home pages has repeatedly found that the vast majority — in recent years around 95-96% — have detectable WCAG 2 failures, with missing text alternatives consistently among the most common issues found. A scanned PDF menu with zero underlying text is exactly that kind of failure, just wearing a restaurant's branding. (WebAIM: The WebAIM Million)
Online Ordering and Reservations Carry the Same Risk
Once the menu itself is fixed, the next place to look is the ordering and reservation flow — often a third-party widget embedded from a delivery platform or reservation system, which means the restaurant doesn't control its code but still owns the guest experience it produces.
Date and time pickers, item customization modifiers ("no onions," "add extra cheese," "choose your side"), and cart controls are all interactive components. Under 2.1.1 Keyboard, every one of them needs to be fully operable without a mouse — a guest who tabs through the page rather than clicking should be able to reach and use every control. And under 4.1.2 Name, Role, Value, each control needs to be properly labeled and identified so a screen reader announces what it actually is — "quantity, spinner, currently one" rather than an unlabeled button that announces nothing useful at all.
A guest who can't add a burger to their cart because the "+1" control has no accessible name doesn't file a bug report. They just close the tab.
Allergen Information Is Usability, Not Just Compliance
Allergen and dietary labeling deserves its own callout, because getting it wrong isn't only a compliance issue — it's a genuine safety and usability problem for real guests trying to eat dinner.
If "contains nuts" or "gluten-free" is conveyed only through a colored dot or icon with no accompanying text, that fails on two fronts at once. Under 1.4.1 Use of Color, information can't be conveyed by color alone — a colorblind guest scanning a menu of green and red dots has no reliable way to tell them apart. And under 1.1.1 Non-text Content, any meaningful icon needs a text alternative — without one, a screen reader either skips the icon entirely or announces something unhelpful like "image."
The fix is simple: pair every icon with a visible text label ("GF," "Contains Nuts," "Vegan") and make sure that label is actual text, not just baked into the graphic. It costs almost nothing to add and it's one of the fastest wins on this entire list.
Multi-Location Groups: Don't Forget the Location Finder
Restaurant groups running several locations often build a custom map or list widget for "find a location near you" and hours of operation. The same keyboard-access and labeling concerns from the ordering flow apply here too — and a broken location finder isn't an abstract compliance gap, it's a guest who wanted to visit tonight and couldn't figure out where or when.
Before vs. After: Fixing the Most Common Restaurant Accessibility Gaps
| Area | Common Failure (Before) | Accessible Fix (After) |
|---|---|---|
| Menu | Scanned image PDF, no underlying text | Real HTML page with proper heading structure per section (1.3.1) |
| Printable menu | Image-based PDF export | Tagged, text-based PDF built for reading order |
| Online ordering | Unlabeled cart/modifier controls, mouse-only pickers | Full keyboard operability (2.1.1) and proper labels (4.1.2) |
| Allergen info | Color-coded icon only | Icon plus visible text label (1.1.1, 1.4.1) |
| Location finder | Custom map widget, mouse-only | Keyboard-accessible list with clear labels |
Where to Start This Week
You don't need to fix everything on this list before dinner service tonight. Start with the highest-impact, fastest-to-ship item: replace or supplement the scanned PDF menu with a real, text-based HTML version. It's the piece every single guest touches, and it's usually the quickest one to remediate.
From there, move to the online ordering and reservation flow, then allergen labeling, then any location-finder widgets if you're running multiple sites.
Web accessibility lawsuits aren't slowing down — UsableNet's annual ADA Digital Accessibility Lawsuit Report has tracked several thousand federal ADA website lawsuits filed per year in the U.S. in recent years, with plaintiffs' firms increasingly sending pre-suit demand letters before ever filing suit. Hospitality and food service sites, with their heavy reliance on PDFs and third-party ordering widgets, are squarely in that line of fire.
Let's Find Out What Your Guests Can't Order
If you're not sure whether your menu, your ordering flow, or your location finder would survive a screen reader test, that's exactly what we check first. Get your menu and online ordering flow audited, and we'll show you precisely where a blind or keyboard-only guest gets stuck — before it costs you a table or a demand letter.