A restaurant uploads its menu the fastest way available: a photograph or scan of the printed page, saved directly as a PDF, dropped onto the website. It opens fine in a browser tab. It looks completely normal to anyone glancing at it. It is also, to a screen reader, an entirely blank page, because a scanned image saved as a PDF contains no actual text at all, only pixels arranged to look like text. There is nothing for a screen reader to read, not a garbled version of the menu, not a partial version, nothing.
The Stat: Food and beverage is the #2 most-sued industry category under ADA Title III digital accessibility claims, and the Ninth Circuit's ruling in Robles v. Domino's Pizza established that restaurant websites, including their menus, must be accessible under Title III. (Source: Robles v. Domino's Pizza, LLC, 9th Cir. 2019; ADA Title III industry litigation tracking)
Why "It Looks Fine" Is Exactly the Problem
The scanned-PDF menu is a specifically dangerous failure pattern precisely because nothing about testing it visually reveals a problem. Everyone who reviews the site by looking at it, the owner, the web designer, a sighted customer, sees a clean, readable menu and moves on. The failure is entirely invisible to that review method, because the review method itself, looking at a rendered image, is the one thing a scanned PDF actually supports. It takes a screen reader, or a direct attempt to select and copy text from the file, to reveal that there is no text there at all to select, copy, or read aloud.
This is a meaningfully different, and in some ways worse, failure than a poorly labeled but genuinely text-based menu. A text-based menu with some accessibility gaps, missing structure, unclear pricing associations, at least gives a screen reader something to work with. A scanned image PDF gives a screen reader literally nothing, the equivalent of a blind customer being handed a photograph of a menu instead of a menu.
Why Food and Beverage Sits Near the Top of the Litigation List
Restaurant websites are disproportionately represented in ADA Title III digital accessibility litigation for reasons specific to the industry: menus are exactly the kind of content most likely to be delegated to whoever is fastest to update it, often not a developer, with a scan-and-upload workflow being the path of least resistance for a menu that changes seasonally. Combined with the sheer number of restaurant websites that exist relative to other business categories, and the fact that a missing or inaccessible menu is one of the easiest accessibility failures for anyone to document (unlike a subtle DOM-level ARIA issue, a screen reader user encountering total silence where a menu should be is an unambiguous, easily screenshotted failure), the combination produces exactly the litigation volume the data shows.
The Ninth Circuit's 2019 ruling in Robles v. Domino's Pizza is the foundational case establishing, for a large share of US jurisdictions, that this obligation is real and enforceable: a restaurant's website, specifically including features tied to its physical service like ordering and menu access, must be accessible under ADA Title III as a place of public accommodation. This is not a novel or contested legal theory at this point; it is a settled precedent restaurants are litigated against regularly.
What an Accessible Menu Actually Requires
The fix does not require abandoning PDFs entirely if a downloadable, printable version is genuinely useful to some customers. It requires two things working together. First, the primary, default way a customer encounters the menu on the website should be real, semantic HTML, actual text in actual heading and list structure, not an embedded image or PDF as the only option. Second, if a PDF version is still offered as a supplementary download, it needs to be a genuinely tagged PDF, one built with real text content and structure information (headings, reading order, table structure for prices), not a scan or a photograph. A tagged PDF, exported directly from the original word-processing or design file rather than scanned from a printed copy, retains real, readable text a screen reader can access, this is a meaningfully different production process, not just a different final file format.
A Quick Way to Check Your Own Menu Right Now
There is a fast, direct test that reveals this specific failure without any specialized tooling: open the menu PDF and try to select and copy a line of text from it, the way you would copy a sentence from any normal document. If nothing highlights, or if the "text" you select and paste elsewhere comes out as garbled characters or nothing at all, the file is an image-based scan with no real text content, exactly the failure described above. A genuinely tagged, text-based PDF allows normal text selection throughout, because the underlying content is real text, not a picture of text. This same test works for any PDF on a site, not just menus, and takes under a minute per file, making it one of the highest-value, lowest-effort accessibility checks available for any business relying on PDF documents anywhere in its public-facing content.
Why "We'll Add an Alt-Text Summary" Is Not a Real Fix
A partial fix worth flagging directly because it is common and insufficient: adding a single generic alt-text description to the embedded PDF or image ("Restaurant menu, see PDF for details") without providing the actual menu content in accessible form anywhere. This technically satisfies the letter of an alt-text requirement for the image itself while leaving the substance, the actual dishes, prices, and descriptions a customer needs to make a dining decision, completely unavailable. A screen reader user in this scenario learns that a menu exists without ever learning what is on it, which is not meaningfully better than the silent failure described above, just a differently shaped version of the same underlying gap.
Beyond the Menu Itself
The menu is usually the single highest-visibility content on a restaurant site, but the same accessibility discipline needs to extend to online ordering, reservation booking, and any location or hours information, exactly the digital services Robles v. Domino's specifically extended Title III coverage to as part of the underlying business's physical service. Our existing restaurant menu accessibility guide covers the practical how-to for the full menu-conversion process in more depth, and our accessibility statement and VPAT guide is worth pairing with it if you want to document your remediation work publicly; this piece is written specifically to make the legal exposure concrete rather than repeat that technical walkthrough.
If your restaurant's menu currently lives only as a scanned or photographed PDF, that is worth fixing this week, not as an eventual project. Our ADA compliance guide covers the broader legal context this sits inside, and our team is reachable directly at experts@wcag.world if you want help converting a specific menu quickly. The ADA's own web accessibility guidance and ADA Title III litigation tracking resources are both worth reading directly for the complete legal picture.