Restaurant website accessibility: menus, ordering and reservations

Updated September 26, 2026 · 8 min read

Why restaurant websites come up so often

Restaurant sites tend to share a few habits that create accessibility problems: menus built as PDFs or photos, ordering and reservations handed off to a third-party widget, and hours or addresses baked into a graphic instead of typed as text. None of these choices are unusual — they're common shortcuts for busy small businesses. But they're also exactly the kind of thing that shows up in an ADA website demand letter or gets flagged in an automated scan, because a screen reader or keyboard-only visitor can hit a wall at the menu, the "Order Now" button, or the reservation form.

This guide walks through the main problem areas and what a fix generally looks like. It's written for owners and the developers or agencies who maintain these sites. It is not legal advice — if you're responding to a specific legal claim, talk to an attorney.

Menus: PDF and image-only menus

The core problem

A menu that exists only as a PDF scan or a photographed image has no underlying text. A screen reader either reads nothing or, at best, announces "image" with no content. This falls under WCAG 1.1.1 Non-text Content, which asks that meaningful non-text content have a text alternative. A menu is meaningful content — prices, dish names, and dietary notes are exactly what a visitor came for.

PDFs create a second layer of difficulty. Even a "text" PDF exported from a design tool can be visually laid out in a way that reads out of order — columns that jump around, prices disconnected from dish names — which relates to WCAG 1.3.1 Info and Relationships: the reading order and structure need to match what's visually implied.

Practical fixes

The most reliable fix is an HTML menu: real text on the page, using headings for sections (Appetizers, Entrees, Desserts) and a logical order. This also tends to help with search visibility, since search engines can index actual menu text.

If you're not ready to rebuild the menu as HTML, some partial improvements still help:

• Add a plain-text version of the menu on the same page, even below a styled PDF or image version, so the content exists somewhere text-based.
• If you keep a PDF, tag it properly so headings, tables, and reading order are marked up, rather than exporting a flat image-based PDF.
• Avoid menu images with text baked into the graphic (a common design-software habit) — if you must use one temporarily, give it real alt text describing the dishes and prices, though this is a stopgap, not a full solution, since alt text isn't practical for a multi-page menu.
• Make sure any menu section headings are marked as actual headings in the HTML, not just bolded or enlarged text.

Menu text also needs to meet basic readability standards once it's real text: sufficient color contrast against the background (WCAG 1.4.3 Contrast (Minimum)) and the ability to resize without breaking the layout or losing content (WCAG 1.4.4 Resize Text).

Third-party ordering and reservation embeds

Most restaurant sites don't build ordering or reservations in-house — they embed a widget from an ordering platform, a reservation service, or a POS vendor's booking tool. That's a reasonable business decision, but it means the accessibility of that flow is partly outside your control.

What's worth checking on your own site:

• Keyboard access. Can someone tab through the entire ordering or reservation flow — selecting items, choosing a time slot, entering party size — using only a keyboard, with no mouse? This maps to WCAG 2.1.1 Keyboard. Some embedded widgets trap focus or skip interactive elements entirely.
• Visible focus. As someone tabs through, is it visually clear which button or field is currently selected? This is WCAG 2.4.7 Focus Visible, and it's a frequent gap in third-party widgets with custom styling that strips the browser's default focus outline without replacing it.
• Form labels. Fields like "party size," "date," or "special requests" need a real, programmatically associated label, not just placeholder text that disappears once you start typing. This is covered by WCAG 3.3.2 Labels or Instructions.
• Link and button purpose. Buttons like "Order Now," "Reserve," or "Continue" should make sense on their own, including to screen reader users who may jump between elements rather than reading top to bottom — related to WCAG 2.4.4 Link Purpose (In Context).
• Interactive component labeling. Custom dropdowns, date pickers, and quantity steppers built with <div>s instead of native form elements often lack the role and state information assistive technology needs, which is what WCAG 4.1.2 Name, Role, Value addresses.

If a vendor's widget has real accessibility gaps, your options are usually: ask the vendor directly (larger platforms sometimes have an accessibility statement or roadmap), look at whether the vendor offers a more accessible embed mode, or provide an alternative path — for example, a phone number for reservations or ordering, clearly presented, not buried in fine print. An alternative path doesn't fix the widget, but it does mean a visitor isn't left with no way to complete the task.

Hours, address and contact info as real text

Restaurant hours and addresses are often laid into a footer graphic, a hero banner, or a hand-designed "Hours" image that pairs a fun typeface with the schedule. These are usually a bad fit for accessibility for the same reason as image menus: no underlying text, so nothing for a screen reader to read, and nothing that resizes cleanly for someone zooming in.

The fix here is usually simple: put hours, address, and phone number in real HTML text somewhere on the page, even if a styled graphic version also exists elsewhere. It's a small change with a fairly large practical benefit, since this is information people look up quickly and often on a phone, sometimes while walking or driving.

Two related basics worth checking on the same pages:

• The page has an accurate, descriptive <title> (for example, "Hours & Location — [Restaurant Name]" rather than a generic site-wide title), covered by WCAG 2.4.2 Page Titled.
• The page's language is correctly declared in the HTML (lang="en" or the appropriate code), which is WCAG 3.1.1 Language of Page — a small technical detail, but one that affects how screen readers pronounce content.

Popups and overlays

Restaurant sites frequently run a popup on load: a newsletter signup, a reservation prompt, an age gate, or a "we've moved" notice. These need to be operable without a mouse — a keyboard user should be able to reach the close button and dismiss the popup, and focus shouldn't get stuck behind or inside it in a way that blocks the rest of the page. If a popup can't be closed with the keyboard, it can functionally lock out that visitor from the entire site.

It's also worth checking whether there's a way to skip repeated navigation blocks (like a long header menu) to get to the main content, which is what WCAG 2.4.1 Bypass Blocks covers — useful on any site with a long nav bar repeated across many pages, popups or not.

A quick self-check

Before a deeper audit, a few manual checks catch a lot of common restaurant-site issues:

1. Unplug your mouse and try to view the menu, place an order, and make a reservation using only Tab, Shift+Tab, and Enter.
2. Turn on your phone or laptop's built-in screen reader and listen to the menu page. Does it read actual dish names and prices, or nothing useful?
3. Zoom your browser to 200% and check whether the hours, address, and menu are still fully readable and usable.
4. Look at any popup and confirm you can close it without a mouse.

These checks won't catch everything a full WCAG 2.1 AA review would, but they surface the highest-impact restaurant-specific problems quickly. For a fuller picture, a WCAG 2.1 AA checklist walks through the broader set of success criteria, and it can help to run a free scan to get a baseline read on where a given site stands.

Frequently asked questions

Do I have to rebuild my whole menu as HTML right away?

Not necessarily right away, but it's the most durable fix. If a full rebuild isn't feasible immediately, adding a plain-text version alongside the PDF or image menu is a reasonable interim step, since it gives screen reader users and search engines actual text to work with.

Is a tagged, accessible PDF menu good enough?

A properly tagged PDF with correct reading order and real text (not scanned images) is a meaningful improvement over an untagged scan, and can work reasonably well for some users. It generally still isn't as reliable across different screen readers and devices as a plain HTML menu.

My ordering system is a third-party embed I can't edit — what can I do?

Start by testing it with a keyboard and a screen reader to see exactly where it breaks. Then raise the specific issues with the vendor, check if they offer an accessible embed option, and consider adding an alternative like a phone number so visitors aren't blocked if the widget itself has gaps you can't fix directly.

Does adding alt text to my menu image make it compliant?

No single fix "makes" a site compliant, and alt text on a multi-item menu image is a limited stopgap at best — it can't practically convey a full menu with sections, prices, and dietary notes the way real text can. Courts and reviewers vary in how they weigh partial fixes, so treat it as a temporary measure, not a solution.

Where can I read more about how these lawsuits and letters generally work?

The ADA website lawsuits explained guide and the federal filing tracker cover the broader legal landscape, and the demand letter guide walks through what a typical letter says and how to respond. None of this is a substitute for advice from an attorney on your specific situation.

Related

• WCAG 2.1 AA checklist for business websites
• Got an ADA website demand letter? What to do in the first two weeks
• Why a dated accessibility audit record matters

Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.