WCAG 2.1 AA Checklist for Hotels and Hospitality Websites

Hotels and hospitality groups rank second only to eCommerce in volume of US ADA web accessibility lawsuits. UsableNet's 2024 industry report logged roughly 3,400 federal complaints against lodging properties, and that number does not include state filings under California's Unruh Act or New York's State Human Rights Law. The risk profile is unusually concentrated. Most hotel websites lean on a third-party booking widget, a large image carousel for room photography, and a chain navigation that branches into 20 to 2,000 property pages. Each one of those surfaces is a known failure pattern, and there is a federal regulation specifically aimed at hotels that most operators have not heard of.

The DOJ rule almost nobody knows about

28 CFR 36.302(e) is a Department of Justice regulation under ADA Title III that applies only to places of lodging. It requires hotels to identify and describe accessible features of guest rooms in enough detail to permit a person with a disability to assess independently whether the room meets their needs, and to allow accessible rooms to be reserved through the same channels that book any other room. In practice this means three things on your website. Accessible rooms have to appear in the same booking flow as standard rooms (not buried in a separate page), the accessibility features have to be described in plain text, and the booking widget has to let users filter or request the accessible room class without phoning the front desk. Plaintiffs cite this rule constantly because it gives them a federal hook that goes beyond WCAG conformance.

Booking widgets are the single biggest exposure

Most independent hotels and most franchisees embed a third-party booking engine. The big names are SynXis (Sabre), Reserve Direct, Pegasus, TravelClick (Amadeus), Bookassist, and direct integrations from chain CRSs like Marsha (Marriott), Holidex (IHG), and Reservhost (Hyatt). Hotels assume the vendor handles accessibility. The vendor's terms of service usually disclaim it. Courts have repeatedly held the host property responsible for what loads on its domain. What to check on the embed wrapper, regardless of which vendor you use:

• The iframe or hosted booking module has a meaningful title attribute that names what it does (Booking engine, not blank or generic)
• Date pickers are reachable by keyboard alone, with arrow keys to move between dates and Escape to close the calendar
• Room cards in the result list use real headings (h3 or h4), not styled paragraphs, so a screen reader user can jump between rooms
• The accessible-room option uses semantic labels (radio inputs with a real label) and announces what it is, not just ADA Room as styled text
• Price changes update an aria-live region so screen-reader users hear total updates when they change dates or room count
• There is a non-iframe fallback (Call 1-800-xxx-xxxx for reservation help) above or below the widget, in real text

If your booking widget fails any of these and the vendor will not fix it inside their iframe, the realistic path is to add a clearly labeled phone number and email channel on the same page, and document this in your accessibility statement. That fallback channel has saved properties from settlement in several 2023 and 2024 complaints.

Room photo carousels and lightboxes

Every hotel website has a room gallery. Most of them are broken for keyboard users in the same three ways. The arrow keys do not advance the carousel, the close button on the lightbox is unlabeled, and focus stays inside the lightbox after it closes (called a keyboard trap, and a clean WCAG 2.1.2 failure). The libraries that ship with these defects in their out-of-the-box config include Slick (now jQuery legacy), Swiper before version 8, Owl Carousel, and a long tail of WordPress theme bundlers. What a clean carousel looks like:

• Previous and Next buttons are real buttons with aria-label, not styled divs
• Each slide has alt text on the photo that describes what is actually shown (Deluxe King Room with city view, not Image 1)
• Opening a lightbox traps focus inside the lightbox while it is open, then returns focus to the trigger element on close
• Escape closes the lightbox from anywhere inside it
• The slide counter (1 of 12) is announced to screen readers, ideally via aria-live polite

Virtual tours and 360 degree photos

Matterport tours, Kuula scenes, and embedded 360 photos are popular on resort and boutique hotel sites. They are also a near-guaranteed accessibility failure, because the spatial content cannot be described in alt text the way a flat image can. The pattern that works in real audits is to treat the tour as supplementary, not primary, and to provide an equivalent text-or-image alternative on the same page. A short paragraph describing what is in the room, paired with two or three flat photos with proper alt text, satisfies WCAG 1.1.1 for the same content. The tour itself should still have a title and a heading announcing what it shows, and any keyboard controls (rotation, zoom) should be reachable without a mouse.

Accessible room filter and search

This is where the 28 CFR 36.302(e) rule lands directly on the user interface. Your room search needs an accessible room filter or a clearly labeled option to request one in the same flow as a standard room. Many hotels still send accessible-room requests through a separate Contact us page or a Special requests text box at the end of checkout. DOJ guidance and plaintiff attorneys both treat that as non-compliant. The minimum that holds up:

1. Show accessible room types in the main room list, not hidden behind a Show more accessible options link
2. Use real form controls (checkboxes or radio buttons) with visible labels for filtering
3. Include the actual accessibility features in the room description (roll-in shower, visual fire alarm, transfer shower seat, lower closet rod, accessible route from parking) rather than just a single bullet that says Accessible
4. Let the user complete the booking without phoning the property, including selecting the accessible room and providing payment

Multi-property navigation for chains and groups

Hotel groups that run 5 to 50 properties have a brand site that lists all of them. The repeated failure pattern on these:

• Property cards are clickable divs instead of links, so they do not announce as links to screen readers and skip the keyboard tab order
• Maps embed without a title attribute, and there is no text address fallback nearby
• Filter chips (City, Brand, Amenities) are not real form controls, so a screen reader user cannot tell what is selected
• The property switcher dropdown traps focus when opened, with no way to dismiss without clicking outside
• Each property page reuses the same template, so a single missing alt text or unlabeled iframe shows up on every page in the audit

The last point is good news for remediation cost. Fix the template once, every property page improves at the same time. It is also the reason multi-property sites tend to bunch large numbers of identical findings in their first scan.

Group sales, banquet menus, and event PDFs

Most hotels publish a Meetings or Events section with PDFs of floor plans, banquet menus, capacity charts, and group rate cards. These are uploaded once by the sales team and rarely revisited. Two issues show up at every audit. The PDF is a scanned image with no real text underneath, which is invisible to screen readers and counts as a WCAG 1.1.1 failure. The link to the PDF reads as Download (not Download wedding banquet menu PDF, 2.4 MB), which strips the context. Fix both by uploading tagged PDFs with real text, and write link labels that describe what the user is about to open.

Concierge chat widgets and AI assistants

Many properties have added chat or AI concierge widgets in the bottom right of the page. The accessibility issues are consistent. The chat button is not labeled (it reads as a clickable icon), the chat panel opens without moving focus into it, and there is no way to close it with the keyboard. If you cannot configure the widget to fix this, the safest path is to add an alternative contact channel (a tel: link and an email address) on the same page in HTML text, so a user who cannot operate the chat still has a way through.

Mobile experience

Hotel traffic is more mobile than almost any other industry. Two problems we see at nearly every scan:

• Sticky bottom Book Now bars overlap the last 50 to 80 pixels of the page when the user zooms in, which is a WCAG 1.4.10 reflow issue
• Date pickers that work fine on desktop become unusable on mobile because the field zooms in and out unexpectedly, and the keyboard covers the picker

Accessibility statement specifics for hotels

A hotel accessibility statement should explicitly call out the WCAG version (2.1 Level AA), reference the 28 CFR 36.302(e) reservation rule, and provide a phone number staffed during reservation hours for guests who cannot complete a booking through the digital flow. It should also describe the accessible-room booking flow in plain language, including how to specify access needs at booking and what to expect at check-in. Several 2023 and 2024 complaints cited the absence of these specific elements even on properties whose general WCAG scan results were clean.

Quick wins this month

1. Add a title attribute and a tel: fallback to every booking widget iframe and concierge chat widget on the site
2. Audit your room photo carousel for keyboard reachability, alt text quality, and focus return on lightbox close
3. Verify that accessible rooms appear in the main booking flow (not a separate page) and that the booking can be completed without a phone call
4. Replace every scanned PDF in the Meetings and Events section with a tagged PDF that has real text, and rewrite link labels to describe the file
5. Run a baseline WCAG 2.1 AA scan against your sitemap (not just the homepage) and date the report so you have evidence of ongoing remediation