Restaurant Website Accessibility: Menus, Reservations, and Online Ordering

I’ll work through the anti-slop checklist systematically before editing.

Video: Restaurant Website Accessibility: Menus, Reservations, and Online Ordering

0. Archetype alignment: Draft is a Vertical Guide. Structure is sound and restaurant-specific throughout. No generic “six most common failures” section. No forbidden module violations detected. Required modules all present.

1. Hook: Opens with the UsableNet stat + blind-user scenario. The scenario is strong. The hook sentence itself is good. The transition into the intro’s second paragraph is slightly loose – tighten.

2. Generic opener phrases: “Accessibility is a revenue question as much as a legal one” is borderline filler. The Accenture stat already makes the point. Trim or sharpen. No “In today’s digital landscape,” “Let’s explore,” etc. found.

3. Passive voice: A few instances to fix. “Every interactive element in an ordering flow must be keyboard accessible” is fine (actor is genuinely distributed). “The QR code should resolve to your accessible HTML menu page” – fine. “The success message must be announced” – fix.

4. Filler sentences: Several found. “The failures that trigger these claims are not obscure technical edge cases” in para 2 of intro – good, keep. “This is a problem that many businesses face” type sentences not present, but “The structure is straightforward” in HTML menu section is mild filler. “The four-part formula for restaurant food photography alt text” paragraph opener is fine.

5. Bullet-point overuse: The article uses mostly tables and numbered steps rather than bullets. The WCAG requirements section uses bold-label format which reads as pseudo-bullets – that’s appropriate for the content. Acceptable.

7. Weasel stats: All stats are attributed. “Independent keyboard-navigation tests” for Resy is slightly vague – tighten. “Some guests with motor disabilities” is accurate hedging, not weasel language.

8. Structural balance: Sections are proportional. No imbalance flagged.

9. The ending: The closing paragraph ends: “knowing your current state is the only way to prioritize what to fix first.” That’s functional but not sharp. Improve.

10. Distinctiveness: Opening is distinctive. Closing paragraph is generic. Fix.

11. Article-shape variety: Feels operational and industry-specific. Correct shape for Vertical Guide.

12. Source/section repetition: No repeated opening stat across articles in this cluster. Restaurants article opens with UsableNet industry-specific finding (most-targeted industry), not the 3,117 lawsuit count as first sentence. Real estate article opened with the 3,117 count. Dental article also opened with 3,117 count. This article correctly opens differently. The 3,117 figure appears later in its own section, which is appropriate.

House style checks: – Em dashes: multiple present throughout. Replace all with periods, commas, colons, or parentheses. – En dashes: used in ranges (e.g., “$5,000 – $15,000”) – these are acceptable numeric ranges, keep. Check for en dashes used as connectives. – AI-generated filler: “The structure is straightforward” – remove. “That gives a blind user the information they need” – tighten. “The core legal principle here is straightforward and consistently upheld by courts” – tighten. – Vary paragraph rhythm: a few sections have same-length paragraphs in sequence. Address. – Specificity: “Independent keyboard-navigation tests” needs more specificity or cut the hedge.

Now editing:

---

Restaurants and food-service businesses were the single most-targeted industry for web accessibility lawsuits in 2025, according to UsableNet’s 2025 Year in Review. That fact becomes concrete the moment you follow a blind user through a typical restaurant website. She navigates to the menu. Her screen reader announces “image” and moves on. She tries to book a table. The date picker requires a mouse click. She attempts to order online. The “Add to Cart” button has no accessible name. Three separate failures, three separate WCAG violations, one lost order.

The failures that trigger these claims are not obscure technical edge cases. They are the core workflows every restaurant website is built around: finding the menu, booking a table, placing an order. This guide covers exactly what restaurant website accessibility requires for each of those workflows, with a 20-item checklist you can use to audit your own site today.

---

What Is Restaurant Website Accessibility?

Restaurant website accessibility means ensuring your menus, reservation systems, and online ordering tools work for guests with disabilities, including those who use screen readers, keyboard-only navigation, or have low vision. The legal benchmark is WCAG 2.2 Level AA, required under ADA Title III for any restaurant website that connects to a physical location or accepts orders online.

WCAG 2.2 is organized around four principles, each one directly relevant to how guests use restaurant sites. Perceivable: your menu content must be available in text form, not just as an image. Operable: every button, date picker, and quantity stepper must work with a keyboard alone. Understandable: error messages on your reservation form must explain what went wrong and how to fix it. Robust: your ordering flow must work with assistive technology like screen readers and switch controls, not just with a mouse and a modern Chrome browser.

People with disabilities in the United States hold nearly $500 billion in disposable income, according to Accenture’s 2023 Disability Inclusion report. That figure excludes the spending power of their families, friends, and advocates. Accessibility is a revenue question, not only a legal one.

---

Does Your Restaurant Website Have to Be ADA Compliant?

Yes. Every restaurant website, regardless of size, is covered under ADA Title III.

ADA Title III requires that places of public accommodation not discriminate against people with disabilities. Courts have consistently extended this to websites connected to physical businesses. The foundational case is Robles v. Domino’s Pizza (9th Circuit, 2019), in which the court held that Domino’s website and app were subject to ADA Title III because they connected to a physical restaurant. The ruling applies to every restaurant, not just national chains. A single-location diner is covered the same as a 500-location franchise. Courts have applied WCAG 2.1 AA (and increasingly WCAG 2.2 AA) as the de facto technical standard for evaluating compliance, and the DOJ’s 2024 final rule formalized WCAG 2.1 AA as the benchmark for covered entities. There is no safe harbor for small businesses, no size exemption, and no compliance deadline. Enforcement is entirely lawsuit-driven, and any guest who encounters a barrier can file a complaint the same day.

Even restaurants with no online ordering carry risk. A menu published as a scanned image PDF, with no underlying text layer, fails WCAG Success Criterion 1.1.1 and has been cited as a standalone basis for ADA complaints. That single document is sufficient to generate a demand letter. For broader context on ADA website requirements beyond restaurants, see our guide on ADA website compliance requirements.

---

Why Restaurants Are the Most-Sued Industry for Digital Accessibility

According to UsableNet’s 2025 Year in Review, approximately 3,117 federal web accessibility lawsuits were filed in 2025, a 27% increase over 2024. Including state court filings, the total exceeded 5,000 cases. Restaurants led all industries for digital accessibility claims.

The reason is partly structural. Restaurant websites share a common failure profile: scanned PDF menus, third-party reservation widgets, and unlabeled ordering buttons. That combination creates multiple claimable violations on a single visit. Serial plaintiffs target restaurants specifically because settlements are economical. The typical figure is $5,000 – $15,000, compared to $25,000 or more in litigation costs if the restaurant contests the claim.

The instinct to install an accessibility overlay backfires. According to UsableNet’s 2025 data, approximately 22.6% of web accessibility lawsuits targeted websites that already had an overlay installed. Overlays do not fix scanned PDF menus. They do not remediate an inaccessible OpenTable iframe. They do not label an unlabeled “Add to Cart” button. In 2025, the FTC reached a settlement requiring accessiBe, one of the largest overlay providers, to pay $1 million over misleading marketing claims that its product guaranteed ADA compliance and protected clients from lawsuits. It did not. The FTC enforcement action and the lawsuit data belong together: overlays are a liability, not a fix.

---

Accessible Restaurant Menus: HTML, PDF, and the QR Code Gap

The menu is the first thing most guests look for on a restaurant website, and it is the most common single source of accessibility lawsuits against restaurants. The reason comes down to format.

Why Scanned PDF Menus Fail

A scanned PDF is a rasterized image of a document. There is no underlying text layer. The file is functionally identical to a photograph. When a screen reader opens it, it announces “image” and moves on. The guest hears nothing. This is a clear failure of WCAG 1.1.1 (Non-text Content), and it has been cited in restaurant accessibility complaints more than any other single issue.

The quick test: open your menu PDF and try to click and drag to select text. If you cannot select any text, it is a scanned image.

A tagged PDF is different. A native PDF exported directly from design software, rather than scanned, can contain a real text layer, defined reading order, and accessibility tags. A properly structured tagged PDF can pass WCAG 1.3.1. But it still requires pinch-and-zoom on mobile, it is harder to maintain when your menu changes, and it offers no SEO benefit (Google cannot index scanned PDF content either). Tagged PDFs are a stopgap. HTML is the long-term solution.

Building an Accessible HTML Menu

An HTML menu page is the only format that is fully accessible, fully indexable by Google, and genuinely usable on mobile without pinch-zoom. Use <h2> or <h3> elements for category names (Appetizers, Entrées, Desserts), <ul> and <li> elements for items, and include item name, description, and price as text within each list item. Prices must appear as text in the same element as the item, not floated visually with CSS positioning that creates a disconnect in the reading order.

Allergen information must appear as plain text beside each item. Color-coded icons without text labels, a red dot for “contains nuts,” a yellow dot for “contains dairy,” fail users who are colorblind and fail screen reader users entirely. “Contains: nuts, dairy” in plain text is the minimum.

Daily specials are a common gap. A JPEG photograph of a chalkboard has zero accessibility. An editable CMS field, or a short HTML text block updated by staff, passes.

The QR Code Menu Gap

Post-COVID, QR code menus became standard across the industry. The accessibility problem is not the QR code itself. It is what the QR code resolves to.

A QR code that links to a scanned PDF carries exactly the same failure as serving that PDF directly. The guest scans the code, opens the file, and finds an image their screen reader cannot parse. Two steps, same barrier.

The fix is simple: your QR code should resolve to your accessible HTML menu page, the same URL your website menu navigation links to. There should be no separate “QR menu” PDF that lives outside your normal site structure.

One secondary issue is worth noting. Some guests with motor disabilities cannot hold a phone steady enough to scan a QR code reliably. A text link on the same table card ensures they do not need to.

Comparison of restaurant menu formats by accessibility and compliance risk.

Menu Format	Screen Reader	SEO Indexed	Mobile UX	Maintenance	Accessibility Risk
HTML page	✅ Full support	✅ Yes	✅ Responsive	Medium	Low
Tagged PDF	⚠️ Partial	⚠️ Limited	❌ Pinch-zoom	High	Medium
Scanned PDF	❌ No support	❌ No	❌ Pinch-zoom	Low	High – lawsuit target
Menu image (JPEG/PNG)	❌ No support	❌ No	❌ Varies	Low	High – lawsuit target

Food Photography Alt Text

Every meaningful food photograph on your menu or ordering page needs descriptive alt text. “dish1.jpg” and blank alt attributes both fail WCAG 1.1.1.

Use this four-part formula for restaurant food photography: dish name + key ingredients + preparation method + portion cue. For example: “Pan-seared duck breast with cherry reduction and roasted fingerling potatoes, plated for two.” That gives a blind user the information needed to make an ordering decision, including whether the portion fits their situation. Generic advice to “describe the image” misses the portion cue entirely, which is the detail blind users specifically say they need when ordering.

Background and purely decorative ambiance images, the moody shot of your dining room, the abstract texture in a banner, should use alt="" so screen readers skip them. Decorative images with populated alt text create unnecessary noise.

---

Making Your Restaurant’s Reservation System Accessible

OpenTable, Resy, and Third-Party Widget Liability

Embedding a third-party widget on your domain makes you responsible for its accessibility. Courts have consistently held this. The restaurant gets sued, not the platform.

OpenTable maintains a public accessibility statement and targets WCAG 2.2 Level AA. However, older iframe embed configurations can fail focus management. A keyboard user tabbing through your reservation page may get trapped inside the OpenTable iframe, unable to Tab out without using a workaround most users will not know exists. OpenTable’s self-reported compliance does not guarantee your specific embed configuration passes. Test your actual embed, not the platform’s accessibility statement.

Resy has mixed keyboard support in practice. Date picker widgets have failed keyboard-navigation testing in specific embed configurations. The date field may not be reachable by Tab, or the calendar may require mouse clicks to navigate. Contact Resy directly to request the most current accessible embed configuration, and test it yourself before trusting the response.

The 60-second test any restaurant owner can run: unplug your mouse, go to your reservation page, and press Tab. Can you reach the date field? Can you select a date using arrow keys or by typing? Can you choose a time, enter party size, and reach the submit button, all without touching a mouse? If you get stuck at any point, your widget fails WCAG 2.1.1.

If your widget is not fixable in the short term, add a clearly visible telephone reservation option on the same page. This does not remove legal liability, but it demonstrates good faith accommodation and ensures guests are not simply abandoned.

Accessible Built-In Reservation Forms

For restaurants building their own booking forms, the reservation form accessibility requirements are specific.

Reservation Form Accessibility Checklist

Requirement	Pass Criteria
Every field has a <label> element	Not placeholder text alone. Labels persist when the field is filled
Date picker is keyboard navigable	Tab to field, type date in MM/DD/YYYY, or use arrow keys in calendar
Error messages identify the specific field	“Please enter a date in MM/DD/YYYY format,” not “Form error”
Errors are associated with fields via aria-describedby	Screen reader announces the error when the field receives focus
Time selector is keyboard accessible	Dropdown or typed input, not custom JS-only time pickers
Success confirmation is announced to screen reader	Focus moves to confirmation message on submission

---

Online Ordering Accessibility: Every Step of the Journey

According to the Click-Away Pound Survey 2019, 69% of disabled online consumers click away from websites they find difficult to use because of their disability. For a restaurant with online ordering, that is a revenue problem on every single order, not a UX problem to revisit later.

WCAG Requirements for Restaurant Ordering Flows

Every interactive element in an ordering flow must be keyboard accessible and work with a screen reader. The specific requirements map to restaurant ordering like this:

Menu item cards: The action button must have a unique, descriptive accessible name. <button>Add Grilled Salmon to order</button> passes. Ten buttons each labeled “Add” fail WCAG 4.1.2. The screen reader cannot distinguish them.

Quantity steppers (+ / -): Icon-only buttons with no text fail WCAG 4.1.2. Each button needs an accessible name: aria-label="Increase quantity" and aria-label="Decrease quantity". The current quantity value should be announced when it changes.

Customization modals: When a guest opens a customization dialog (choose your protein, select add-ons), focus must move into the modal and be contained within it while the modal is open. When they close it, focus must return to the item that triggered it. This is WCAG 2.4.3 (Focus Order). A modal that does not manage focus correctly is one of the most disorienting failures a screen reader user can encounter.

Tip selector: Radio buttons or clearly labeled buttons. Amounts that are only visually apparent, three boxes with no accessible labels, fail.

Order summary: Must be reachable via keyboard and readable in logical sequence: item name, then quantity, then price. CSS-only positioning that creates a visual layout disconnected from the DOM reading order breaks this.

Checkout confirmation: Use role="alert" or move focus directly to the confirmation element. Silently resetting the form leaves a blind user with no confirmation their order was placed.

For the keyboard-specific requirements across ordering controls, see our guide on keyboard accessibility for ordering forms.

First-Party vs. Third-Party Ordering: Who Is Liable

First-party ordering (built into your own site): you control every element and carry full responsibility. You also have full ability to fix issues.

Third-party embedded ordering (a widget from a delivery platform embedded on your site): same rule as reservation widgets. Your domain, your liability. The platform’s accessibility statement does not protect you.

Third-party linked ordering (an “Order on DoorDash” button that takes the guest off your site): clicking the link transfers the ordering experience to another domain. You cannot control that platform’s accessibility, but your liability for the off-site experience is limited. You remain responsible for making the link button itself accessible: keyboard focusable, labeled, and passing contrast requirements. Include a phone ordering alternative in your accessibility statement for users who cannot use the third-party platform.

If you have a choice between embedding a third-party ordering widget and linking out to it, linking out reduces your exposure. The safest path is a first-party ordering system where you control the code.

---

Restaurant Website Accessibility Checklist

Use these 20 items to self-audit your site before running an automated scan. This restaurant website accessibility checklist covers the five areas where failures are most common and most legally significant.

#	Category	Item	Pass Criteria
1	Menus	Menu available as HTML or properly tagged PDF	Text is selectable; no scanned images
2	Menus	Food images have descriptive alt text	Includes dish name, ingredients, preparation, portion cue
3	Menus	Daily specials are HTML text, not JPEG	Editable CMS field or HTML section
4	Menus	QR code links to accessible HTML menu page	No PDF destination
5	Menus	Allergen info appears as text, not color only	“Contains nuts” in text form
6	Reservations	All form fields have visible <label> elements	Not placeholder-only
7	Reservations	Date picker operable by keyboard	Tab + arrow keys navigate calendar
8	Reservations	Error messages identify the specific field	Not just “Form error”
9	Reservations	Success confirmation announced to screen reader	Focus moves to confirmation message
10	Reservations	Third-party widget passes Tab-only navigation	Test with mouse disconnected
11	Ordering	“Add to order” buttons have unique accessible names	“Add Grilled Salmon” not just “Add” ×10
12	Ordering	Quantity steppers labeled (+ / -)	aria-label on each button
13	Ordering	Customization modal traps and returns focus	Focus cycle within modal; returns on close
14	Ordering	Order summary readable in logical sequence	Screen reader announces name → qty → price
15	Ordering	Checkout success message announced	role="alert" or focus management
16	Images	Hero and ambiance images are decorative or described	alt="" for pure decoration; formula-based alt for food
17	Navigation	Main nav keyboard accessible	All items reachable by Tab
18	Navigation	Skip-to-content link present	First Tab stop on page
19	Typography	Menu and body text meets 4.5:1 contrast ratio	Test with contrast checker
20	Mobile	Site usable on mobile with keyboard/switch access	No tap-only interactions

---

How to Test Your Restaurant Website for Accessibility

Automated scans catch roughly 30 – 40% of accessibility issues. The rest require manual testing. Use both, in this order.

Step 1 – Automated scan: Run a free website accessibility checker on your homepage, your menu page, your reservation page, and your ordering flow. An automated scan will immediately flag missing alt text, color contrast failures, missing form labels, and empty button names: the failures most likely to appear in a demand letter.

Step 2 – Keyboard-only walkthrough: Unplug your mouse. Tab through your site in this exact sequence: (a) navigate to the menu and read at least three items, (b) open a reservation and complete it with keyboard only, (c) start an online order, add an item, and reach the checkout. If you cannot complete any of these steps without a mouse, that stage fails WCAG 2.1.1.

Step 3 – Screen reader test: Turn on VoiceOver (Mac: Cmd + F5) or NVDA (free on Windows). Navigate your menu and ordering flow. Listen specifically for: buttons announced without a purpose, food images with no description, form fields that receive focus without announcing their label.

Step 4 – Color contrast check: Run your menu text colors through a contrast checker, particularly text placed over food photography backgrounds and low-contrast specials typography. The minimum for body text is 4.5:1 (WCAG 1.4.3).

Step 5 – Mobile test: Complete a reservation and an order on a mobile device using iOS VoiceOver or Android TalkBack. Mobile is where restaurants lose the most users. Image-heavy layouts and tap-only interactions that pass on desktop fail consistently on mobile assistive technology.

For agencies doing deeper technical audits, the Browser Accessibility Tree and DevTools guide covers how to inspect computed accessible names, roles, and states directly in Chrome DevTools. Useful for diagnosing unlabeled buttons and focus management failures in ordering flows.

---

Frequently Asked Questions About Restaurant Website Accessibility

What happens if my restaurant website is not accessible?

Under ADA Title III, any guest who encounters an accessibility barrier can file a complaint or pursue a lawsuit. Settlements typically run $5,000 – $15,000; litigation can exceed $50,000 in attorney fees if the restaurant contests the claim. The DOJ may also pursue enforcement independently under its 2024 final rule, which established WCAG 2.1 AA as the required standard. Beyond legal risk, inaccessible ordering flows mean lost revenue from the roughly 66 million US adults living with a disability.

How much does fixing restaurant website accessibility cost?

Replacing a scanned PDF menu with an accessible HTML page typically costs $200 – $800 as a one-time development task. A full accessibility audit and remediation for a small restaurant site generally runs $1,500 – $5,000 depending on complexity. Small businesses may qualify for the IRS Section 44 Disabled Access Tax Credit, up to $5,000 to offset accessibility improvement costs. Consult your accountant to confirm eligibility for your specific situation.

Does my restaurant need an accessibility statement?

An accessibility statement is not legally required, but it is strongly recommended. The DOJ references accessibility statements as a signal of good faith, and they provide a contact mechanism for guests who encounter barriers. That matters because only 8% of disabled users who encounter difficulty on a website will contact the owner to report it, according to the Click-Away Pound Survey 2019. The other 92% simply leave. Place an accessibility statement link in your footer and include: the compliance standard you are targeting (WCAG 2.2 AA), any known limitations such as a third-party reservation widget under remediation, and a contact email for accommodation requests.

Is a QR code linking to a PDF menu an ADA violation?

If the PDF is a scanned image, rasterized with no selectable text, yes. It fails WCAG 1.1.1 and creates the same liability as serving the menu as an inaccessible image directly. If the PDF is a properly tagged native PDF with selectable text and logical reading order, the risk is lower but not eliminated: tagged PDFs still fail many users on mobile. The safest path is linking the QR code to your accessible HTML menu page. No separate QR-only PDF, no format that lives outside your normal site structure.

---

The checklist tells you what to look for. A scan of your actual site tells you what you have missed.

Run a free website accessibility checker on your restaurant’s menu page, reservation page, and ordering flow. You will get an instant report on missing alt text, unlabeled form fields, color contrast failures, and empty button names: the specific issues most likely to appear in a demand letter. Treat it as your baseline. Most restaurants find at least one critical failure within the first page scanned, and knowing exactly what is broken is the only way to fix the right thing first.

---

This article is for general informational purposes and does not constitute legal advice. Consult an ADA attorney for specific compliance questions related to your restaurant.

Also relevant: Real Estate Website Accessibility: Listings, Tours, and Applications and Section 508 Compliance: Who It Covers and How to Test.