Accessible Digital Menus

Why This Is a Real Risk and Not a Scare Story

The numbers are worth stating carefully, because this topic attracts inflated ones. According to Seyfarth Shaw’s annual count — the standard industry tally of ADA Title III federal filings — plaintiffs filed 3,117 website accessibility lawsuits in federal court in 2025, a 27 percent increase over 2024. That was 36 percent of all 8,667 ADA Title III suits filed federally that year, up from 28 percent the year before. New York federal courts alone saw 1,021 of them.

Restaurants are a place of public accommodation under Title III, and their websites and menus are routinely among the targets. What makes menus specifically vulnerable is that the standard restaurant menu on the internet is a PDF exported from a print design file, which is close to the worst-case artifact for assistive technology.

Here is the part vendors gloss over: the ADA itself specifies no technical standard for private businesses. The Department of Justice’s 2024 rule setting WCAG 2.1 Level AA as the standard applies to state and local government entities, not to restaurants. In Title III litigation, WCAG 2.1 AA has nonetheless become the de facto benchmark courts and settlements reference. That is a meaningful distinction: there is no checkbox that makes you compliant, which is exactly why no vendor can sell you one.

So the honest framing is not “buy this and you are safe”. It is that a menu built as real HTML text starts from a defensible position, and a menu that is a PDF or a JPEG starts from an indefensible one.

What Goes Wrong With a PDF Menu, Specifically

It is worth being concrete, because “PDFs are bad for accessibility” gets repeated without anyone explaining the mechanism.

A PDF describes where marks go on a fixed page. Unless it was deliberately tagged during export — and menus exported from design software almost never are — it carries no heading structure, no reading order, and often no reliable text layer at all. A screen reader given an untagged menu may read prices before dish names, may read columns across instead of down, or may find nothing but an image.

That last case is the most common and the most complete failure. A great many restaurant menus on the internet are not documents containing text; they are documents containing a picture of text, exported at print resolution. To software, there is nothing there to read. To a low-vision guest, enlarging it produces a blur rather than bigger words.

Then there is the phone problem, which affects everyone. A fixed page geometry cannot reflow, so enlarging text means panning around a page in two dimensions, one-handed, at a table. For a guest with limited dexterity or low vision that is not an inconvenience, it is a wall.

None of this is fixed by putting a QR code in front of it. The code is a doorway; the accessibility problem is entirely in the room behind it.

What We Do, and What We Cannot Promise

What a Web Gerek menu gives you by construction: every dish name, description and price is real HTML text, not an image. Categories and items carry a genuine heading hierarchy, so a screen reader can move through the menu by section instead of reading it start to finish. The page reflows to any screen size and respects the guest’s own text-size settings rather than fighting them. It works with the browser’s built-in translation, which matters more than most operators realise. And it is a mobile-first layout rather than a desktop page squeezed onto a phone.

What we cannot promise, and what you should distrust any vendor for promising: that your menu is ADA compliant. Compliance is a property of your whole guest-facing estate assessed against a standard that, for private businesses, is not formally specified. It depends on choices you make after we hand you the tools — the colour contrast of the design you pick, whether you upload photos with meaningful alternative text, whether your dish descriptions are comprehensible, and on the rest of your website, which we did not build.

If accessibility is a live concern for you — because you have received a demand letter, because you are a chain, or because you simply want to get it right — the correct next step is an audit against WCAG 2.1 AA by someone who does that for a living. Starting from HTML makes that audit cheaper and its findings fixable. Starting from a PDF usually means the auditor’s first recommendation is to stop using a PDF.

Frequently Asked Questions