Warum Hospitality besonders häufig beklagt wird
Zwei Regulierungsbehörden, eines der dichtesten Fallregister in der digitalen Barrierefreiheit.
In den Vereinigten Staaten sind Hotels die dominierende ADA-Title-III-Beklagtenbranche neben dem E-Commerce und Restaurants. Serienkläger zielen gezielt auf den Reservierungsvorgang und die Zimmerbeschreibungsseite — dort haftet die durch ADA Title III definierte Pflicht am sichtbarsten an Web-Inhalten, und ein einzelnes unzugängliches Widget kann Dutzende nahezu identische Klagen begründen. Der Fall Acheson Hotels v. Laufer schien kurzzeitig die Klagebefugnis von Tester-Klägern einzuschränken; im Oktober 2023 wies der Oberste Gerichtshof ihn als gegenstandslos ab und ließ die zugrundeliegende Zugangspflicht unberührt.
Die DOJ-Reservierungssystemregel nach 28 CFR 36.302(e) begründet bereits eine konkrete Pflicht: barrierefreie Zimmer zu identifizieren, ihre Barrierefreiheitsmerkmale so detailliert zu beschreiben, dass eine informierte Buchung möglich ist, und sie über dieselben Kanäle buchbar zu machen wie nicht barrierefreie Zimmer. Diese Regel gilt seit 2010 und ist gegenüber Hotels unabhängig von ihrer allgemeinen Web-Barrierefreiheitspostur durchsetzbar. Sie ist als separate Konformitätslinie zu behandeln, die parallel zu WCAG läuft.
Restaurantketten stehen vor demselben Risikomuster, wobei die Speisekarte das wiederkehrende Ziel ist. PDF-only-Speisekarten — eine aus dem Druckbetrieb übernommene Gewohnheit — sind das am häufigsten genannte Problem in Beschwerden über Restaurant-Websites; QR-Code-Karten, die zu unzugänglichen PDFs führen, sind ein naher zweiter Platz. Online-Bestellvorgänge und Reservierungsabläufe (eingebettete OpenTable-, Resy-, Tock-Widgets) fügen dem eigenen Marketing-Website der Kette eine eigene Audit-Oberfläche hinzu.
In der Europäischen Union nennt der European Accessibility Act „Personenverkehrsdienste" in seiner Anwendungsliste, und die breitere Tourismus-Wirtschaft wird durch nationale Umsetzungsvorschriften erfasst. Fluggesellschaften sind gesondert unter dem ECAC-Rahmen und den EU-Fluggastrechteverordnungen abgedeckt, mit eigenen technischen Konformitätsanforderungen an Buchungs- und Check-in-Oberflächen. Die Barrierefreiheitspflicht erstreckt sich über die gesamte Reise-Kaufkette, nicht nur auf die Website, die die Kreditkarte entgegennimmt.
OTAs — Booking.com, Expedia, Agoda, Trip.com, Hotels.com, Vrbo, Airbnb — tragen die Pflicht für die Oberflächen, die sie betreiben. Ein Hotel kann seine Pflicht nach 28 CFR 36.302(e) nicht abwälzen, indem es genaue Barrierefreiheitsdaten an eine OTA übermittelt, die diese entfernt oder verbirgt; das Hotel bleibt die öffentliche Einrichtung. Doch die OTA als eigenständiger digitaler Dienstleister schuldet ihrerseits eine ADA-Title-III-Pflicht (in den USA) und eine EAA-Pflicht (in der EU) für ihre eigene Website und App. Beide Seiten der Übergabe müssen barrierefrei sein.
Die Kosten von Verstößen sind konkret. ADA-Vergleiche für Hotels und Restaurants liegen typischerweise im Bereich von 20.000–50.000 USD für Erstbeklagte und erheblich höher für Wiederholungsfälle. In der EU wechselte die Durchsetzung von der Abmahnungsphase, die den Großteil von 2025 dominierte, in die Bußgeldphase 2026 in Deutschland, Frankreich, Italien, Spanien und den Niederlanden. Hospitality steht klar im Fokus beider Regulierungsregime.
Die 30-Punkte-Hospitality-Checkliste
Sechs Oberflächen × fünf Prüfpunkte. Ausdrucken, abhaken, dann auditieren.
-
01 Buchungsmaschine
-
02 Zimmer- und Inventarbeschreibung
-
03 Speisekarten & Gastronomie
-
04 Treueprogramm & Konto
-
05 Karten & Standort
-
06 Kundenservice & Sonderwunschanfragen
Implementierungshinweise je Plattform
Wo die Checkliste im Code tatsächlich greift — nach Plattformfamilie.
Sabre / Amadeus / Oracle Hospitality (Legacy-CRS/PMS)
Die drei großen Reservierungssysteme sind modernen Web-Barrierefreiheitserwartungen um Jahrzehnte voraus, und die Storefront-UIs, die sie umhüllen, sind oft agenturgefertigte Oberflächen auf Synxis (Sabre), iHotelier (Amadeus) oder OPERA Cloud (Oracle). Das VPAT oder die EN-301-549-Erklärung der Plattform sagt wenig darüber aus, was die eigene Oberfläche tatsächlich ausliefert. Die wiederkehrenden Probleme sind: Datumsbereichsauswähler ohne role="grid", Zimmerkarten-Raster aus Divs ohne Tabellensemantik und Tarifvergleichstabellen aus positionierten Span-Elementen. Die Barrierefreiheitserklärung der Plattform als Untergrenze behandeln, dann die eigene Oberfläche auditieren.
Mews / Cloudbeds / Hotelogix (moderne PMS)
PMS-Anbieter der neueren Generation liefern in der Regel bessere Grundsemantik in ihren Buchungsmaschinen-Widgets — echte Formularbeschriftungen, fokussierbare Datumsauswähler, aria-live-Regionen bei Tarifänderungen. Der Fallstrick ist die White-Label-Theming-Schicht: Wenn die Buchungsmaschine an das Design-System des Hotels angepasst wird, überschreibt die beauftrage Agentur häufig Fokus-Styles, gestaltet den Kalender um und bricht die Barrierefreiheitspostur auf, die die Plattform geliefert hatte. Das Barrierefreiheits-Testprotokoll der Agentur anfordern — nicht nur die Plattformerklärung.
SiteMinder / RateGain (Channel-Manager)
Channel-Manager sind vorwiegend Backend-Systeme — sie verteilen Inventar an OTAs und den GDS, anstatt Endkunden direkt zu bedienen. Ihre Barrierefreiheitspflicht ist enger, aber real: Die von Hotelmitarbeitern genutzte Verwaltungskonsole muss für Mitarbeiter mit Behinderungen bedienbar sein, und die downstream übermittelten strukturierten Daten (insbesondere der nach 28 CFR 36.302(e) erforderliche Barrierefreiheitsmerkmal-Payload) müssen die Zuordnung überleben. Zwei Dinge auditieren: die mitarbeiterseitige Konsole und eine Stichprobe der tatsächlich an Booking.com, Expedia und die GDS-Endpunkte gelieferten Payloads.
OpenTable / Resy / Tock (Restaurant-Reservierung)
Restaurant-Reservierungsplattformen werden typischerweise über iFrames oder Widget-Skripte in Restaurant-Websites eingebettet. Das dominierende Fehlerbild ist die iFrame-Grenze — Fokusverwaltung über die Grenze ist fragil, die Landmark-Struktur des Screenreaders bricht zusammen, und Skip-Links erreichen das Widget nie. Das Widget zuerst als eigenständige URL auditieren (die meisten Plattformen stellen eine bereit), dann eingebettet in die eigene Website, dann den Buchungsbestätigungsablauf zurück zur eigenen Domain. Drei Audits, nicht eines.
Booking.com / Expedia / Trip.com (OTAs)
OTAs laufen auf einem anderen Audit-Zyklus als die Hotels, die sie auflisten. Als Hotel kann Booking.com nicht auditiert werden — aber es kann auditiert werden, wie das eigene Inventar dort erscheint und ob der über SiteMinder oder den Channel-Manager übermittelte Barrierefreiheits-Payload tatsächlich im OTA-Eintrag erscheint. Als OTA gilt die Pflicht für die gesamte Oberfläche: Suche, Filter, Eintragsdetail, Checkout, Konto und die mobile App. OTAs werden zunehmend als eigenständige Beklagte nach ADA Title III und dem EAA benannt — nicht als Ableitung der Pflicht des zugrunde liegenden Hotels.
Toast / Square / Lightspeed (POS + digitale Speisekarte)
POS-gebündelte digitale Speisekarten und QR-Code-Bestelloberflächen sind die neueste Klagefläche in der Restaurant-Barrierefreiheit. Das beim Scan gerenderte Menü ist HTML, aber die Standard-Templates der Plattform überspringen häufig semantische Überschriften, verwenden rein symbolbasierte Allergen-Badges ohne Textäquivalent und rendern Gerichtbilder ohne Alternativtext. Die meisten Plattformen bieten inzwischen Barrierefreiheitseinstellungen auf Theme-Ebene an — diese aktivieren, dann den tatsächlichen gerenderten Output auditieren, nicht den Marketing-Seiten-Screenshot der Plattform vom Aussehen der Speisekarte.
Der Monitoring- + Audit-Zyklus
Eine einmalige Behebung übersteht keine einzige saisonale Speisekarten-Aktualisierung.
Hospitality-Websites ändern sich ständig. Unterkünfte veröffentlichen dienstags Saisonpakete, das F&B-Team tauscht donnerstags die Abendkarte aus, das Marketing veröffentlicht am Wochenende ein Feiertagsbanner. Eine einmalige Barrierefreiheitsbehebung hält etwa so lange wie der nächste Zimmertypstart — weshalb das Modell, das tatsächlich trägt, drei Ebenen hat, nicht eine.
Zunächst einen kostenlosen WCAG-2.2-Scanner gegen die Live-Website laufen lassen, um eine Ausgangslage für die Buchungsmaschine, die Zimmerbeschreibungsseiten und die Speisekarten zu ermitteln. Dann kontinuierliches automatisiertes Monitoring gegen jeden Preview-Build und jeden Produktions-Deploy einbinden — das ist die Schicht, die Regressionen abfängt, bevor es der Gast tut, und die Schicht, die die meisten Teams überspringen, bis sie ihre erste Abmahnung erhalten. Drittens mindestens jährlich ein manuelles Audit durch Testerinnen und Tester mit Behinderungen in Auftrag geben — und nach jedem größeren Redesign, OTA-Integrations-Rollout oder PMS-Replatforming. Automatisiertes Testing erkennt nie die Screenreader- Lesbarkeit einer Weinkarte, die Fokusreihenfolge in einem Mehrraum-Buchungsablauf oder ob der barrierefreie Zimmeranfrage-Workflow tatsächlich von Anfang bis Ende nutzbar ist.
Für das Monitoring + manuelle Audit-Handoff im Besonderen behandelt unser Monitoring-Einkaufsleitfaden die Plattformen, die den Scan-bis-Audit-Workflow von Anfang bis Ende abwickeln — Qualibooth, axe Monitor, Siteimprove und Level Access. Die Auswahl sollte nach Integrationstauglichkeit mit dem CI und danach erfolgen, ob das manuelle Audit-Netzwerk der Plattform tatsächlich Testerinnen und Tester mit den Behinderungen einschließt, die die Gäste haben — nicht alle tun das. Für die PDF-Oberfläche, die Hospitality-Teams nicht vermeiden können (Gruppenpreisblätter, Bankettmenüs, Barrierefreiheitserklärungen), das Monitoring mit unserem Leitfaden zu barrierefreien PDFs von A bis Z kombinieren.
FAQ
Die Fragen, die Hospitality-Teams stellen, bevor sie sich engagieren.
Fallen mobile Hotel-Apps unter die ADA?
In der Praxis ja. Bundesgerichte haben ADA Title III wiederholt auf mobile Apps angewendet, die mit Diensten öffentlicher Einrichtungen verbunden sind — Hotel-Apps gehören zu den eindeutigsten Beispielen, da Buchungs-, Zimmerschlüssel- und Concierge-Funktionen wesentliche Hospitality-Dienste sind, die digital erbracht werden. Das DOJ hat offiziell die Position eingenommen, dass die ADA für Web- und Mobile-Angebote öffentlicher Einrichtungen gilt, und Anwaltskanzleien für Serienklage-Mandanten reichen inzwischen routinemäßig Klagen gegen Hotel-Apps ebenso wie gegen Hotel-Websites ein. iOS- und Android-Apps sind als separate Audit-Oberflächen vom Marketing-Website zu behandeln.
Verpflichtet die DOJ-Reservierungsregel Hotels zur Beschreibung barrierefreier Zimmer auch bei Dritt-OTAs?
28 CFR 36.302(e) verpflichtet Hotels dazu, barrierefreie Zimmer zu identifizieren und so detailliert zu beschreiben, dass eine Person mit Behinderung beurteilen kann, ob das Zimmer ihren Bedürfnissen entspricht, und diese Zimmer über dieselben Kanäle wie nicht barrierefreie Zimmer buchbar zu machen. Die Regel bindet das Hotel als öffentliche Einrichtung. In der Praxis geben Hotelgruppen diese Pflicht an nachgelagerte Stellen weiter — sie übermitteln strukturierte Barrierefreiheitsdaten an Booking.com, Expedia und die großen GDS-Feeds — doch wenn die OTA diese Daten entfernt, trägt das Hotel weiterhin die Verantwortung. OTA-Einträge sind als Konformitätsoberfläche zu behandeln, nicht als Problem anderer.
Wie mache ich eine PDF-Speisekarte barrierefrei?
Die ehrliche Antwort lautet: keine PDF-Speisekarte verwenden. PDF ist das falsche Format für ein bestellförderndes Dokument, das auf einem Smartphone mit Screenreader funktionieren muss. Wenn die Karte als PDF ausgeliefert werden muss (aus Gründen der Druckparität oder gesetzlicher Anforderungen), muss sie mit einer korrekten Lesereihenfolge getaggt sein, echten Text statt gescannter Bilder enthalten, barrierefreie Tabellen für das Preisgitter aufweisen und Alternativtext für jede dekorative Abbildung tragen — siehe unseren Leitfaden zu barrierefreien PDFs von A bis Z. Die deutlich bessere Antwort ist, eine HTML-Speisekarte zu veröffentlichen, die PDF als optionalen Download zu verlinken und den Kampf mit Acrobat aufzugeben.
Benötigen dynamische Preisfilter in einer Buchungsmaschine besondere Barrierefreiheitsbehandlung?
Ja. Das wiederkehrende Fehlerbild ist das stille Re-Rendering: Die Person verschiebt einen Preisfilter, die Zimmerliste ordnet sich neu, und nichts teilt dem Screenreader mit, dass sich die Ergebnisse geändert haben. Den Ergebnisbereich in einem aria-live="polite"-Container einschließen, nach jeder Filteränderung eine Ansage auslösen („12 Zimmer entsprechen Ihren Filtern") und sicherstellen, dass der Fokus an einem sinnvollen Ort bleibt. Der Schieberegler selbst sollte role="slider" mit aria-valuemin, aria-valuemax und aria-valuenow exponieren — die meisten modernen Schieberegler-Komponenten tun dies, die meisten selbst entwickelten nicht.
Wie hoch ist das Klagerisiko für eine Restaurantketten-Website mit unzureichender Barrierefreiheit?
Hoch und konzentriert. Restaurantketten gehören neben Hotels und dem E-Commerce zu den am häufigsten beklagten ADA-Title-III-Beklagten. Der Fall Acheson Hotels v. Laufer erreichte 2023 den Obersten Gerichtshof und wurde schließlich als gegenstandslos abgewiesen, was bedeutet, dass die zugrundeliegende Zugangspflicht nie eingeschränkt wurde — Serienklage-Einreichungen haben sich fortgesetzt. Das restaurantspezifische Risiko konzentriert sich auf die Speisekarte (insbesondere PDF-only-Karten), den Online-Bestellvorgang, den Reservierungsvorgang (eingebettete OpenTable-/Resy-/Tock-Widgets) und das Treueprogramm-/Konto-Portal. Vergleichssummen von 20.000–50.000 USD für Erstbeklagte sind typisch; Wiederholungsfälle zahlen erheblich mehr.
Stellen QR-Code-Speisekarten in Restaurants ein Barrierefreiheitsrisiko dar?
Das können sie, auf zwei verschiedene Arten. Erstens der QR-Code selbst: Wenn die einzige Möglichkeit, die Karte zu lesen, das Scannen eines QR-Codes mit einer Smartphone-Kamera ist, werden Gäste ausgeschlossen, deren Telefon gesperrt, leer oder nicht vorhanden ist — das ist ein Dienstleistungsproblem, kein reines WCAG-Problem, landet aber in denselben Beschwerden. Zweitens die Seite, auf die der QR-Code verweist: Ist es ein PDF oder eine JavaScript-lastige SPA, die mit einem Screenreader nicht funktioniert, wurde eine unzugängliche Karte von Papier auf das Telefon verlagert. Immer eine gedruckte oder vorgelesene Alternative anbieten; immer sicherstellen, dass die verlinkte Seite echtes HTML und WCAG 2.2 AA-konform ist.
Drei nächste Schritte
Den Schritt wählen, der zum aktuellen Stand der eigenen Unterkunft passt.
-
Kostenlosen Scanner jetzt starten
Ein Live-kostenloser WCAG-2.2-Scanner gegen jede öffentliche URL — Buchungsmaschine, Zimmerbeschreibungsseite oder Restaurantspeisekarte. Bester Einstieg, wenn keine aktuelle Ausgangslage für die digitalen Oberflächen der Unterkunft vorliegt.
-
Den Standard nachschlagen
Die 30-Punkte-Checkliste oben ist konkreten WCAG-2.2-Erfolgskriterien zugeordnet. Die Standardseite nutzen, wenn ein Prüfer gefragt wird, welches Kriterium eine bestimmte Behebung abdeckt.
-
Manuelles Audit beauftragen
Unseren Leitfaden zur Beauftragung eines manuellen Audits durch Testerinnen und Tester mit Behinderungen lesen — was anzufordern ist, welches Budget einzuplanen ist und welche Plattformen ein echtes Tester-Netzwerk umfassen versus es auslagern.