Why hospitality is uniquely litigated
Two regulators, one of the densest dockets in digital accessibility.
In the United States, hotels are the dominant ADA Title III defendant industry alongside ecommerce and restaurants. Serial-plaintiff filings specifically target the reservation flow and the room-description page — that is where the duty defined by ADA Title III most visibly attaches to web content, and where a single inaccessible widget can support dozens of near-identical complaints. The Acheson Hotels v Laufer case briefly looked like it would narrow tester-plaintiff standing; in October 2023 the Supreme Court dismissed it as moot, leaving the underlying access duty intact.
The DOJ's reservation-system rule at 28 CFR 36.302(e) already imposes a specific obligation: identify accessible rooms, describe their accessibility features in enough detail to permit informed booking, and make them reservable through the same channels as non-accessible rooms. That rule has been in force since 2010 and is enforceable against hotels regardless of their web-accessibility posture in general. Treat it as a separate compliance line item that runs parallel to WCAG.
Restaurant chains face the same shape of risk, with the menu as the recurring target. PDF-only menus — a habit inherited from print operations — are the single most-cited issue in restaurant-website complaints; QR-code menus that resolve to inaccessible PDFs are a near-second. Online ordering and reservation flows (OpenTable, Resy, Tock embeds) add their own audit surface on top of the chain's own marketing site.
In the European Union, the European Accessibility Act names "passenger transport services" in its scope list, and the broader tourism economy is covered through national implementing regulations. Airlines are covered separately under the ECAC framework and EU passenger-rights regulations, with their own technical conformance expectations on booking and check-in surfaces. The accessibility duty sits across the entire travel-purchase journey, not just the website that takes the credit card.
OTAs — Booking.com, Expedia, Agoda, Trip.com, Hotels.com, Vrbo, Airbnb — bear the duty for the surfaces they own. A hotel cannot offload its 28 CFR 36.302(e) obligation by feeding accurate accessibility data into an OTA that strips or hides it; the hotel remains the public accommodation. But the OTA, as a separate digital service provider, owes its own ADA Title III duty (in the US) and EAA duty (in the EU) on its own website and app. Both sides of the handoff have to be accessible.
The cost of getting this wrong is concrete. Hotel and restaurant ADA settlements typically land in the $20,000–$50,000 range for first-time defendants and materially higher for repeat targets. In the EU, enforcement moved from the warning-letter phase that dominated most of 2025 into the fine-issuing phase in 2026 across Germany, France, Italy, Spain, and the Netherlands. Hospitality is squarely in the crosshairs of both regimes.
The 30-point hospitality checklist
Six surfaces × five checks. Print it, tick it, then audit it.
-
01 Booking engine
-
02 Room & inventory description
-
03 Menus & dining
-
04 Loyalty & account
-
05 Maps & location
-
06 Customer service & accommodations request
Platform-by-platform implementation notes
Where the checklist actually lands in code, by platform family.
Sabre / Amadeus / Oracle Hospitality (legacy CRS/PMS)
The big three reservation backbones predate modern web-accessibility expectations by decades, and the storefront UIs that wrap them are often agency-built skins on top of Synxis (Sabre), iHotelier (Amadeus) or OPERA Cloud (Oracle). The platform's own VPAT or EN 301 549 statement says little about what your skin actually ships. The recurring issues are: date-range pickers that don't expose role="grid", room-card grids built from divs without table semantics, and rate-comparison tables rendered as positioned spans. Treat the platform's a11y statement as a floor, then audit your skin.
Mews / Cloudbeds / Hotelogix (modern PMS)
The newer-generation PMS vendors generally ship better baseline semantics on their booking-engine widgets — real form labels, focusable date pickers, aria-live regions on rate changes. The gotcha here is the white-label theming layer: when you brand the booking engine to match your hotel's design system, the agency that ships the theme often overrides focus styles, restyles the calendar, and breaks the accessibility posture the platform shipped. Ask for the agency's accessibility-testing protocol, not just the platform's a11y statement.
SiteMinder / RateGain (channel managers)
Channel managers are mostly back-office — they distribute inventory to OTAs and the GDS rather than serving end customers directly. Their accessibility duty is narrower but real: the management console used by hotel staff must be operable by employees with disabilities, and the structured data they pass downstream (especially the accessibility-features payload required by 28 CFR 36.302(e)) must survive the mapping. Audit two things: the staff-facing console, and a sample of the payloads actually delivered to Booking.com, Expedia, and the GDS endpoints.
OpenTable / Resy / Tock (restaurant reservation)
Restaurant-reservation platforms are typically embedded in restaurant websites via iframes or widget scripts. The dominant failure mode is the iframe boundary — focus management across the boundary is fragile, screen-reader landmark structure collapses, and skip-links never reach the widget. Audit the widget as a standalone URL first (most platforms expose one), then audit it embedded in your site, then audit the booking-confirmation flow that hands off back to your domain. Three audits, not one.
Booking.com / Expedia / Trip.com (OTAs)
OTAs sit on a different audit cycle than the hotels they list. As a hotel, you cannot audit Booking.com — but you can audit how your inventory appears there, and whether the accessibility-features payload you pass through SiteMinder or your channel manager actually renders on the OTA listing. As an OTA, the duty is on the entire surface: search, filter, listing detail, checkout, account, and the mobile app. OTAs are increasingly named as defendants in their own right under both ADA Title III and the EAA — not as a derivative of the underlying hotel's duty.
Toast / Square / Lightspeed (POS + digital-menu)
POS-bundled digital menus and QR-code ordering surfaces are the newest litigation surface in restaurant accessibility. The menu rendered at scan-time is HTML, but the platform's default templates often skip semantic headings, use icon-only allergen badges with no text equivalent, and render dish images without alt text. Most platforms now expose theme-level accessibility settings — turn them on, then audit the actual rendered output, not the platform's marketing-page screenshot of what the menu is supposed to look like.
The monitoring + audit cycle
A one-time fix doesn't survive a single seasonal menu refresh.
Hospitality sites change constantly. Properties launch seasonal packages on Tuesday, the F&B team swaps the dinner menu on Thursday, marketing ships a holiday hero over the weekend. A one-time accessibility fix lasts about as long as your next room-type launch — which is why the model that actually holds is three layers, not one.
First, run a free WCAG 2.2 scanner against your live site today to establish a baseline across the booking engine, the room-description pages, and the menu surfaces. Second, plug in continuous automated monitoring against every preview build and every production deploy — this is the layer that catches regressions before the customer does, and the layer most teams skip until they receive their first demand letter. Third, commission a manual audit by testers with disabilities at least annually, and after any major redesign, OTA-integration rollout, or PMS replatform. Automated tooling will never catch screen-reader legibility on a wine-list page, focus-order intent on a multi-room booking flow, or whether the accessible-room request workflow is actually usable end-to-end.
For the monitoring + manual-audit handoff specifically, our monitoring buyer's guide covers the platforms that handle the scan-to-audit workflow end-to-end — Qualibooth, axe Monitor, Siteimprove, and Level Access. Pick on integration fit with your CI and on whether the platform's manual-audit network actually includes testers with the disabilities your guests have — not all of them do. For the PDF surface that hospitality teams cannot avoid (group-rate sheets, banquet menus, accessibility statements), pair the monitor with our accessible PDFs end-to-end playbook.
FAQ
The questions hospitality teams ask before they buy in.
Are hotel mobile apps in scope under the ADA?
In practice, yes. Federal courts have repeatedly applied ADA Title III to mobile apps tied to public-accommodation services — hotel apps among the clearest examples, because the booking, room-key, and concierge functions are core hospitality services delivered digitally. The DOJ has formally taken the position that the ADA applies to web and mobile properties of public accommodations, and serial-plaintiff firms now file routinely against hotel apps as well as hotel websites. Treat the iOS and Android apps as separate audit surfaces from the marketing site.
Does the DOJ reservation rule require accessible room descriptions on third-party OTAs?
28 CFR 36.302(e) requires hotels to identify and describe accessible rooms in enough detail to let a person with a disability decide whether the room meets their needs, and to make those rooms reservable through the hotel's reservation system. The rule attaches to the hotel as the public accommodation. In practice, hotel groups push that obligation downstream — they pass structured accessibility-feature data to Booking.com, Expedia, and the major GDS feeds — but if the OTA strips it, the hotel still owns the duty. Treat OTA listings as a compliance surface, not as someone else's problem.
How do I make a PDF menu accessible?
The honest answer is: don't use a PDF menu. PDF is the wrong format for an order-driving document that has to work on a phone with a screen reader. If the menu has to ship as a PDF (for print parity or regulatory reasons), it must be tagged with a correct reading order, real text not scanned images, accessible tables for the price grid, and alternative text for any decorative imagery — see our guide to accessible PDFs end-to-end. The much better answer is to publish an HTML menu, link the PDF as an optional download, and stop fighting Acrobat.
Do dynamic price filters in a booking engine need special accessibility treatment?
Yes. The recurring failure mode is silent re-rendering: the user slides a price filter, the room list re-shuffles, and nothing announces to a screen reader that the results changed. Wrap the result region in an aria-live="polite" container, anchor an announcement after each filter change ("12 rooms match your filters"), and confirm focus stays in a sensible place. The slider itself should expose role="slider" with aria-valuemin, aria-valuemax, and aria-valuenow — most modern slider components do this, most custom-built ones do not.
What's the litigation exposure for an inaccessible restaurant chain website?
High, and concentrated. Restaurant chains sit in the top tier of ADA Title III defendants alongside hotels and ecommerce. The Acheson Hotels v Laufer case reached the Supreme Court in 2023 and was ultimately mooted, which means the underlying access duty was never narrowed — serial-plaintiff filings have continued. Restaurant-specific risk concentrates on the menu (especially PDF-only menus), the online-ordering flow, the reservation flow (OpenTable / Resy / Tock embeds), and the loyalty / account portal. Settlement ranges of $20,000–$50,000 for first-time defendants are typical; repeat targets pay materially more.
Are restaurant QR-code menus an accessibility risk?
They can be, in two different ways. First, the QR code itself: if your only way to read the menu is to scan a QR code with a smartphone camera, you have excluded the customer whose phone is locked, dead, or absent — that's a service-delivery issue, not strictly a WCAG one, but it lands in the same complaints. Second, the page the QR code points to: if it's a PDF, or a JavaScript-heavy SPA that doesn't render with a screen reader, you've moved an inaccessible menu from paper to phone. Always offer a paper or read-aloud alternative; always ensure the linked page is real HTML and WCAG 2.2 AA.
Three next steps
Pick the one that matches where your property is today.
-
Run the free scanner now
A live free WCAG 2.2 scanner against any public URL — booking engine, room-description page, or restaurant menu. Best place to start if you have no current baseline across your property's digital surfaces.
-
Reference the standard
The 30-point checklist above maps to specific WCAG 2.2 success criteria. Use the standard page when an auditor asks you to cite which criterion a given fix lands against.
-
Commission a manual audit
Read our guide to commissioning a manual audit by testers with disabilities — what to ask for, what to budget, and which platforms include a real tester network versus contracting it out.