For most restaurants, the answer is: go HTML. A PDF can be made accessible, but the scanned or design-export menu most restaurants post is a picture of text that a screen reader cannot read at all — and because menus change constantly, a fixed PDF doesn’t stay fixed. An HTML menu page is cheaper to maintain, works on phones, and shows up in search. Keep a designed PDF for printing if you like it; just stop making it the only way to read your menu.
Here’s how to make that call for your own menu, what the interim fix looks like while you decide, and the conversion steps most articles on this topic skip.
Are PDF menus ADA compliant?
The format isn’t the violation — the implementation usually is. Nothing in the ADA bans PDFs, and a PDF built with real text, tags, a logical reading order, and labeled headings can meet WCAG 2.1 AA, the standard US courts and the DOJ consistently point to. Our accessible PDF guide covers exactly what that takes.
The problem is what restaurants actually upload. The Bureau of Internet Accessibility, in its piece on why PDF menus are a problem, notes that menu PDFs are often image-only — a scan or photo with no text layer — and that even text-based PDFs without proper tags can be read out of order, so “the reader might hear the name of entrée, followed by the description of a completely different menu item.”
So when someone asks “are PDF menus ADA compliant?”, the honest answer is: yours probably isn’t, because it was almost certainly exported for print, not tagged for assistive technology.
Why a scanned menu is a blank page to a blind diner
A scanned menu contains zero readable text — it’s pixels arranged to look like text. A screen reader works by reading the text layer of a document aloud or rendering it in braille. Point one at a photo of your menu and there is nothing to read. The user hears the filename, maybe “graphic,” and silence. Your appetizers, your prices, your gluten-free notes: all invisible.
This is why “images of text” gets its own rule in WCAG — Success Criterion 1.4.5 exists because a picture of words locks out anyone who needs the words as text, including people who enlarge text, translate it, or listen to it.
And a menu is not decorative content. It’s the single piece of information a customer needs before deciding to give you money. When that decision point is unreadable, the barrier is obvious, easy to document, and easy to put in a complaint.
Restaurants are the most-sued industry — calmly noted
The litigation numbers are worth knowing, not panicking over. In 2025, plaintiffs filed 3,948 ADA website lawsuits in the US, and the restaurant, food, and beverage sector ranked first among targeted industries with 1,368 of them — 34.65% of all filings, per EcomBack’s 2025 annual lawsuit report. More than one in three of these suits named a food business.
The precedent behind them started with a pizza order. In Robles v. Domino’s, a blind customer couldn’t order through the website and app with his screen reader. The Ninth Circuit held in January 2019 that the ADA applies to the website and app of a business with physical locations (Southeast ADA Center case history), the Supreme Court declined to hear Domino’s appeal in October 2019, and in June 2021 the district court ordered Domino’s to bring its website into line with WCAG. The case, filed in 2016, finally settled in June 2022 — six years of litigation over an online food order.
You don’t need to be Domino’s-sized to be named. Serial filers work through lists of local restaurants precisely because the barriers are so consistent: unreadable menu, unlabeled buttons, broken reservation form. The menu is usually exhibit A. For the wider picture, see our restaurant accessibility page.
Fix the PDF or go HTML? The actual math
Choose based on how often your menu changes — that variable decides everything. Re-tagging is not a one-time cost; every new export wipes your accessibility work.
| Factor | Tagged PDF | HTML menu page |
|---|---|---|
| Screen reader support | Good if tagged correctly | Native — HTML is what screen readers are built for |
| Menu changes seasonally | Re-tag after every export | Edit text in your CMS, structure survives |
| Who can update it | Specialist with Acrobat Pro skills | Anyone who can edit your website |
| Phones | Pinch-and-zoom on a letter-size page | Reflows to the screen |
| Google can read it | Only if it has a real text layer | Yes, fully |
| Print handout | Its original job — keep it for this | Print stylesheet, or keep the PDF as backup |
If your menu is genuinely static — a tasting menu that changes yearly, a banquet packet — remediating the PDF once is defensible. For everything else, the PDF loses on maintenance alone. Fixing it properly means correct tags, reading order, heading structure, and real text, every single time you update it. Meanwhile the HTML version needs that structure built once.
This is the same conclusion BOIA reaches: HTML “is widely supported by screen readers and other types of assistive technology,” loads faster, and handles mobile better (BOIA). The wider document problem — contracts, catering packets, event flyers — is its own topic, covered in our post on the PDF compliance gap.
The one-hour interim fix
While you plan the real conversion, do this today: paste your menu as plain text onto the page that currently links to the PDF. Not a screenshot — actual typed text. Sections as text, dishes and prices under them. It will not win design awards, and it removes the core barrier immediately: a screen-reader user can now read what you serve.
Two details make the stopgap cleaner. Label the PDF link honestly — “Download menu (PDF)” — so nobody clicks into a dead end unwarned. And if the page uses images anywhere else, give them proper alt text while you’re in there.
How to convert a PDF menu to a web page
The conversion is smaller than most owners expect, because a menu is structurally simple: sections, items, descriptions, prices. Here is the walkthrough:
- Extract the text. If your PDF has a real text layer, copy it out. If it’s a scan, type the menu out or pull it from whatever source document the designer used. Proofread prices carefully — OCR guesses.
- Create a menu page on your site at a sensible URL like
/menu/. Every mainstream platform — WordPress, Squarespace, Wix, Shopify — handles this with a standard page. - Structure it with real headings. The menu name is the page’s H1. Each section — Starters, Mains, Desserts, Drinks — is an H2. This isn’t cosmetic: headings are how screen-reader users jump straight to Desserts instead of listening to the whole menu. Our guide to heading structure and landmarks shows the pattern.
- Keep each item as text: name, description, price. Mark dietary symbols in text too — “(GF)” or “vegetarian” — rather than as icon images alone, and don’t rely on color alone to flag anything.
- Check your contrast. Menu designs love thin gray type on cream. Body text needs a 4.5:1 contrast ratio; test it in a color contrast checker in seconds.
- Update every link and QR code — site nav, Google Business Profile, Instagram bio, table tents — to point at the new page.
- Keep the designed PDF as a secondary download below the menu, linked as “Printable menu (PDF)”. Primary version: HTML. Print artifact: PDF. Everyone gets what they need.
For a typical single-location menu this is an afternoon of work, most of it typing.
The SEO upside nobody mentions to you
People search for menus constantly — “your restaurant name menu” plus dish-level searches like “best birria tacos near me.” A scanned PDF gives Google almost nothing to rank. Google indexes PDFs by extracting their human-readable text (Google Search Central); a photo of a menu has no text to extract.
An HTML menu page, by contrast, is fully indexable: every dish name, every description, every “gluten-free” note becomes text Google can match to a search. The accessible choice and the findable choice are the same choice — a pattern we see across the board in accessibility and SEO.
Where the menu fits in the bigger picture
One caveat, offered honestly: converting the menu removes your most visible barrier, not your only one. The complaints that hit restaurants also cite unlabeled navigation, reservation widgets that trap keyboards, and image-heavy homepages with no alt text. A fixed menu on a broken site is progress, not protection — and none of this is legal advice; if you’ve received a demand letter, talk to an attorney.
The efficient move is to see the whole list at once. Our free accessibility scan checks your site — menu page included — and shows you what a plaintiff’s tester would find, so you can fix the menu this week and plan the rest with real information instead of guesswork.