WCAG 2.1 AA Checklist for Restaurants and Multi-Location Hospitality

Restaurants and multi-location hospitality groups are among the most frequently named defendants in ADA web accessibility lawsuits. The reason is structural: a typical restaurant website is image-heavy, leans on PDF menus that nobody updates, and embeds third-party reservation or ordering widgets that the operator does not control. Each one of those is a known failure surface. This is the working checklist we apply when scanning a restaurant site, ordered by how often each category shows up in real demand letters.

PDF menus are the single biggest risk

A scanned image of a menu, exported to PDF and uploaded to a CDN, is functionally invisible to screen readers. This is the most cited single finding in restaurant accessibility complaints. Two paths to fix it:

1. Replace PDF menus with HTML menus on the site itself, using semantic headings, lists, and prices
2. If a PDF must remain, export it as a tagged PDF with real text (not an image scan), check it with PAC 2024 or Adobe accessibility checker, and add an alt link that says menu text version

An HTML menu is also better for SEO, faster to update, and easier to translate. The accessibility win comes for free.

Online ordering and reservation widgets

Many restaurants embed Toast, OpenTable, Resy, ChowNow, or Square. The operator assumes the vendor handles accessibility. The vendor disclaims it in their terms of service. Courts have consistently held the host site responsible for what loads on it. What to check on the embed wrapper:

• iframe has a meaningful title attribute (Reservation booking, not blank)
• There is a non-iframe fallback link (Book by phone or email) for users with assistive tech that struggles with embeds
• The widget container has a visible heading announcing what loads inside
• Loading states have a screen-reader-readable announcement, not just a spinner

Hero images, looping video, and food reels

Restaurant homepages routinely auto-play 4 to 8 second loops of food being plated, drinks being poured, kitchens at service. WCAG 2.1 AA does not ban motion but it does require:

• Anything that auto-plays for more than 5 seconds needs a pause control
• Anything that auto-plays needs to honor prefers-reduced-motion
• Hero images carrying brand or product information need alt text written by a human
• Background videos must not contain essential information that is unavailable elsewhere on the page

Multi-location pages

Chains and multi-location operators tend to have a Locations page that lists 10 to 50 locations. The repeated failures here:

• Address blocks formatted as one big string, no semantic structure for screen readers
• Hours rendered as images of tables (a known accessibility anti-pattern)
• Each location card with a map embed but no title attribute on the iframe
• Phone numbers as plain text without tel: links, painful for keyboard users on desktop and unusable for assistive dialers

What works

Each location should be a structured block with a heading (the location name), a postal address using semantic markup (or microdata), a tel: link for the phone number, and a list-formatted hours table built from real th and td cells. The map embed needs a clear title and a non-map text address fallback above or below it.

Hours, holidays, and seasonal menus

Most restaurant sites we scan still show a Closed for the holidays banner from two seasons ago because the marketing team owns the site and engineering owns accessibility. This matters because outdated hours appearing only as an image with no alt text is technically a WCAG 1.1.1 failure even though it feels like a content problem. Banner systems should always render text in HTML, not as image overlays.

Mobile experience

Most restaurant traffic is mobile. Two issues we see at every other scan:

• Sticky bottom Order Now or Reserve bars that overlap content, blocking access to the last 60px of every page when zoomed
• Hamburger menus that trap keyboard users (no Escape, no focus return to the menu button on close)

Accessibility statement specifics for restaurants

A restaurant accessibility statement should explicitly call out: the WCAG version (2.1 Level AA), how to request the menu in an alternate format (large print, plain text email), and a phone number staffed during business hours for guests who cannot complete a reservation through the digital widget. Many demand letters cite the absence of this fallback channel even when the rest of the site scans clean.

Quick wins this week

1. Replace any image-only menu PDF with an HTML version, or upload a tagged PDF with real text
2. Add a title attribute to every reservation, ordering, and map iframe
3. Add a tel: link to every phone number on locations pages
4. Audit your hero video for prefers-reduced-motion and a pause control
5. Run a baseline scan (axe-core or equivalent) and date the report so you can show ongoing remediation