Blog
Wir haben 51 österreichische Hotelwebsites gescannt. Keine einzige würde bestehen.
Eine Auswertung von 51 DACH-Hotelwebsites und 830 Seiten aus Juni 2026. Median-Score: 70. Websites ohne kritische Fehler: zwei. Was tatsächlich kaputt ist — und was die Reparatur kostet.
11 min read
Jeder Anbieter für Barrierefreiheit zitiert dieselbe Zahl: die WebAIM Million, die auf rund 95 % der Startseiten der eine Million meistbesuchten Websites erkennbare WCAG-Fehler findet. Eine gute Zahl. Aber eben eine Zahl über Startseiten, überwiegend englischsprachig, überwiegend amerikanisch, quer über alle Branchen.
Also haben wir eine eigene erhoben. Nicht auf einer Million Websites, und nicht nur auf Startseiten — sondern auf 51 echten Hotelwebsites im DACH-Raum, mit allen relevanten Seitentypen: Zimmerübersichten, Angebote, Restaurant, Spa, Kontaktformulare und die Direktbuchungsstrecken.
Hier ist der komplette Datensatz und was er aussagt.
Was gemessen wurde
| Websites | 51 Hotelwebsites (Österreich, dazu einige in Süddeutschland) |
| Seiten | 833 angefragt, 830 erfolgreich gescannt (99,6 %) |
| Zeitraum | 7.–21. Juni 2026 |
| Methode | Headless Chrome, vollständiges Rendering, axe-core 4.10 plus deterministische Tastatur-, Fokus- und Textqualitätsprüfungen |
| Standard | WCAG 2.1 AA, gemappt auf EN 301 549 |
| Häusertyp | 4–5 Sterne, privat oder in kleinen Gruppen, mit Direktbuchung |
Zwei Dinge, bei denen wir ehrlich sein müssen, bevor die Zahlen kommen.
Das ist keine Zufallsstichprobe. Diese 51 Häuser wurden als kommerzielle Interessentenliste zusammengestellt — bekannte, gut ausgestattete Betriebe mit professionell gebauten Websites. Wenn überhaupt, verzerrt das die Ergebnisse nach oben. Eine Zufallsauswahl österreichischer Pensionen und Gasthöfe würde nicht besser aussehen als das hier.
Automatisierte Tests haben eine Obergrenze. Scanner decken zuverlässig etwa ein Drittel bis die Hälfte von WCAG 2.1 AA ab. Sie erkennen ein Kontrastverhältnis von 3,1:1 und ein Formularfeld ohne Label. Sie können Ihnen nicht sagen, ob alt="bild" eine brauchbare Beschreibung ist oder ob ein blinder Gast tatsächlich eine Buchung abschließen kann. Jede Zahl unten ist eine Untergrenze, keine Gesamtsumme.
Niemand hat bestanden
Der Score ist nach Schweregrad gewichtet und startet bei 100: Ein kritischer Regelverstoß kostet 8 Punkte, ein schwerwiegender 4, ein mittlerer 1,5, ein geringfügiger 0,5. Existiert irgendein kritischer Fehler, wird die Website bei 70 gedeckelt.
Die Verteilung ist die eigentliche Geschichte. Es ist keine Glockenkurve mit einem langen Ausläufer schlechter Websites — es ist ein Klumpen in den 60ern und 70ern mit überhaupt nichts über 88. Die beste Hotelwebsite der Stichprobe erreichte 88. Die schlechteste 47.
Diese Form verrät die Ursache. Wäre Barrierefreiheit eine Frage von Budget oder Anstrengung, würde man eine Streuung erwarten: manche Hotels investieren, manche nicht. Stattdessen landen fast alle im selben Band. Genau das passiert, wenn die Probleme aus gemeinsamer Infrastruktur stammen — dieselbe Handvoll österreichischer Hotellerie-Webagenturen, dieselben Booking-Engine-Widgets, dieselben WordPress-Themes, dieselbe Gestaltungskonvention von dünner grauer Schrift auf Weiß.
49 der 51 Websites hatten mindestens einen kritischen WCAG-Fehler. Die zwei ohne kritischen Fehler hatten immer noch schwerwiegende und mittlere; eine saubere Website gab es im Datensatz nicht. Im Schnitt verletzte jedes Hotel 11,8 verschiedene WCAG-Regeln.
Was tatsächlich kaputt ist
Der Anfang dieser Liste lohnt einen Moment, weil er nicht das ist, was die meisten erwarten.
Linktext, der nichts sagt — 48 von 51 Websites. Links, die „mehr", „hier" oder „weiterlesen" heißen. Ein sehender Gast liest sie im Kontext: Die Überschrift darüber sagt „Spa", also bedeutet „mehr" eben „mehr zum Spa". Wer per Screenreader die Linkliste durchgeht, hört „mehr, mehr, mehr, hier, mehr". Das ist WCAG 2.4.4 — und der mit Abstand verbreitetste Fehler im gesamten Datensatz.
Textkontrast unter dem AA-Schwellenwert — 47 von 51 Websites, 8.729 einzelne Elemente. Ganz überwiegend hellgraue Fließtexte auf Weiß und weiße Schrift über Fotos. Das ist Hausstil im Hotellerie-Webdesign: zurückhaltend, elegant — und unlesbar für alle ab etwa 55 mit normaler altersbedingter Sehveränderung. Also, nebenbei bemerkt, für einen erheblichen Teil der Gäste, die Fünf-Sterne-Häuser in den Alpen buchen.
Kein sichtbarer Tastaturfokus — 47 von 51 Websites, 6.668 Elemente. Irgendwo im Stylesheet steht eine Zeile, die den Fokusrahmen des Browsers entfernt, weil er auf einem Button unschön aussah — ohne Ersatz. Wer die Website nur mit der Tastatur bedient, sieht nicht, wo er gerade ist. Das ist WCAG 2.4.7, es ist eine einzige CSS-Regel, und es fehlt fast überall.
Zoom deaktiviert — 35 von 51 Websites. Ein maximum-scale=1 oder user-scalable=no im Viewport-Meta-Tag, meist geerbt aus einem Mobile-Theme von vor Jahren. Am Handy kann ein sehbeeinträchtigter Gast Ihre Preise nicht aufziehen. WCAG 1.4.4. Ein kritischer Fehler — und die Reparatur besteht darin, elf Zeichen aus einer Zeile HTML zu löschen.
Zwei Einträge im Diagramm — Inhalt außerhalb von Landmarks und übersprungene Überschriftenebenen — sind als Best Practice markiert, nicht als WCAG-Verstoß. Sie verschlechtern die Screenreader-Navigation spürbar und gehören repariert, aber eine Behörde würde sie nicht beanstanden. Wir halten sie optisch getrennt, damit das Diagramm die Zahlen nicht stillschweigend aufbläht.
Fast alles sind vier Probleme
Über 830 Seiten hinweg schlugen 64 verschiedene Prüfungen mindestens einmal fehl und erzeugten 37.802 einzelne fehlerhafte Elemente. Vier dieser Prüfungen machen 73 % der Gesamtmenge aus.
Das ist der wirtschaftlich nützlichste Befund der Auswertung. Der erste Reflex, wenn ein Scan-Bericht mit 700 Fehlern hereinkommt, ist: Die Website muss neu gebaut werden. Das muss sie fast nie. Kontrast ist eine Palettenentscheidung. Fokussichtbarkeit ist eine CSS-Regel. Landmarks sind fünf Wrapper-Elemente im Template. Unbenannte Links sind meist eine Icon-Button-Komponente, die auf jeder Seite wiederholt wird.
Reparieren Sie vier Dinge im Template, verschwindet die Mehrheit der gemeldeten Fehler auf einen Schlag — nicht weil der Bericht falsch war, sondern weil Template-Probleme sich über Seiten multiplizieren und Template-Korrekturen sich genauso über Seiten teilen.
Die eigentliche Arbeit steckt im langen Ende: die verbleibenden 60 Prüfungen, 27 % der Funde, brauchen Urteilsvermögen. Datumsfelder ohne Label. Buchungskalender, die den Tastaturfokus festhalten. Zahlungs-iframes ohne zugänglichen Namen. Das sind Reparaturen an einzelnen Komponenten — und sie liegen direkt im Weg einer Transaktion.
Die Booking Engine ist nicht besonders — und genau das ist das Problem
Die naheliegende Ausgangsvermutung war, dass Buchungs- und Anfrageseiten die Katastrophenzone sind: Fremdwidgets, komplexe Datumsauswahl, Zahlungs-iframes.
| Seitentyp | Seiten | Kritische Fehler pro Seite | Schwerwiegende pro Seite |
|---|---|---|---|
| Buchung / Anfrage / Kontakt | 69 | 1,46 | 3,19 |
| Startseite | 51 | 1,49 | 3,59 |
| Alle übrigen Seiten | 710 | 1,21 | 2,85 |
Buchungsseiten sind geringfügig schlechter als gewöhnliche Inhaltsseiten und geringfügig besser als Startseiten. Der Abstand ist real, aber klein — nichts von der Klippe, die wir erwartet hatten.
Die richtige Lesart ist nicht „Booking Engines sind in Ordnung". Sie lautet: Die Barrieren sind gleichmäßig verteilt, weil sie aus dem Template stammen und nicht aus einer einzelnen Komponente. Es gibt keinen sauberen Teil einer Hotelwebsite, an den eine kaputte Buchungsstrecke angeflanscht wäre. 28 der 51 Hotels hatten mindestens einen kritischen Fehler auf einer Seite ihrer Buchungs- oder Anfragestrecke.
Rechtlich ist das relevant, denn die Buchungsstrecke ist der Teil, den der European Accessibility Act am eindeutigsten reguliert. Ein Hotel, das Direktbuchungen mit Online-Zahlung annimmt, erbringt eine Dienstleistung im elektronischen Geschäftsverkehr gegenüber Verbrauchern. Die Pflicht liegt beim Hotel — auch dann, wenn das Widget von SiteMinder oder Cloudbeds stammt. Sie können vom Anbieter eine Konformitätserklärung verlangen; die Pflicht abgeben können Sie nicht.
Was die Reparatur kostet
Grober Aufwand, auf Basis dessen, was im Datensatz tatsächlich steckt:
| Korrektur | Wo sie sitzt | Typischer Aufwand |
|---|---|---|
| Sichtbare Fokusstile wiederherstellen | Eine globale CSS-Regel | Unter einer Stunde |
| Pinch-Zoom wieder erlauben | Viewport-Meta-Tag | Minuten |
| Fließtext und Textauflagen auf 4,5:1 abdunkeln | Design-Tokens / Theme | Halber Tag plus Design-Freigabe |
| Landmarks ergänzen, Überschriftenordnung korrigieren | Seiten-Template | Halber Tag |
| Icon-Links und Buttons benennen | Gemeinsame Komponenten | Halber bis zwei Tage |
| „mehr" / „hier" durch echte Linktexte ersetzen | Inhalte, CMS-weit | Laufend; mengenmäßig am größten |
| Buchungsstrecke: Labels, Tastatur, Fehlermeldungen | Booking Engine oder Anbieter | Tage, oder ein Gespräch mit dem Anbieter |
Bei den meisten Häusern der Stichprobe würden schon die ersten vier Zeilen den automatisierten Score innerhalb einer Entwicklerwoche von den 60ern in die 80er heben. Das ist noch keine Konformität — die urteilsabhängige Hälfte von WCAG bleibt davon unberührt. Aber es beseitigt genau die Fehler, die für jeden trivial nachweisbar sind: für eine beschwerdeführende Person, für einen Mitbewerber, für einen automatisierten Scan einer Verbraucherorganisation.
Die letzten beiden Zeilen entscheiden darüber, ob ein Gast mit Behinderung Ihnen tatsächlich Geld geben kann.
Was wir nicht behaupten
Etwas Disziplin zu den Grenzen dieses Datensatzes:
- Keine Behörde hat diese Websites gescannt. Die deutsche Marktüberwachung hat uns schriftlich mitgeteilt, dass eine automatisierte Vorabprüfung des Marktes nicht vorgesehen ist. Niemand lässt einen Crawler laufen, der Sie sucht. Der realistische Auslöser ist eine Beschwerde — von einem Gast, einem Mitbewerber oder einem Interessenverband.
- Eine unserer eigenen Prüfungen ist aus allen Zahlen oben ausgeschlossen. Unser Detektor für Tastaturfallen hat auf 20 Websites angeschlagen; die Handprüfung zeigte, dass er zu oft anschlägt. Er steckt in keiner Zahl dieses Artikels.
- Ein Score ist kein rechtliches Urteil. Keine Zahl irgendeines Scanners, unsere eingeschlossen, belegt Konformität. Sie belegt, dass bestimmte erkennbare Fehler existieren.
- Stichprobe von 51. Groß genug, dass das Muster klar ist. Klein genug, dass Sie sie nicht als Zustandsbeschreibung der gesamten österreichischen Hotellerie zitieren sollten.
Die eine Zahl zum Mitnehmen
Null von 51.
Nicht „die meisten Hotels haben ein paar Baustellen". In einer Stichprobe gut ausgestatteter, professionell gestalteter Vier- und Fünf-Sterne-Hotelwebsites hat kein einziges Haus 90 Punkte erreicht — bei einer automatisierten Prüfung, die nur die einfache Hälfte des Standards misst.
Wenn Sie eines dieser Häuser führen, ist die nützliche Frage nicht, ob Ihre Website Probleme hat; die Grundrate sagt, dass sie welche hat. Die Frage ist, welche vier Template-Korrekturen die meisten davon beseitigen — und ob ein Gast mit Screenreader eine Buchung abschließen kann.
Prüfen Sie Ihre eigene Website
Scannen Sie Ihre Hotelwebsite kostenlos und sehen Sie, wo sie im Vergleich zu den 51 Häusern dieser Auswertung steht. Ohne Kreditkarte, ohne Verkaufsgespräch.
Oder testen Sie zuerst den Sofort-Check ohne Anmeldung auf Ihrer Startseite.
Weiterlesen
- Barrierefreiheit von Hotel-Websites und der EAA: Die Booking-Engine-Falle — warum die Buchungsstrecke rechtlich der entscheidende Teil ist
- EAA-Compliance in Österreich: das BGStG — die österreichische Rechtslage im Detail
- Die 10 häufigsten EAA-Verstöße und ihre Behebung — konkrete Reparaturen zu den Prüfungen aus dieser Auswertung
Quellen
- Webply-Scan-Datensatz: 51 DACH-Hotelwebsites, 830 Seiten, 7.–21. Juni 2026, Scoring-Modell v3. Rohdaten bei Webply; Einzelergebnisse wurden dem jeweiligen Haus mitgeteilt.
- axe-core 4.10, Regeldefinitionen und WCAG-Mapping, Deque Systems.
- Richtlinie (EU) 2019/882 (European Accessibility Act), Artikel 3 Nr. 30 — Definition der Dienstleistungen im elektronischen Geschäftsverkehr.
- EN 301 549 v3.2.1 / WCAG 2.1 Level AA, Erfolgskriterien.
Dieser Artikel berichtet die Ergebnisse automatisierter Barrierefreiheitstests und dient der allgemeinen Information. Er ist keine Rechtsberatung und stellt keine Konformitätsbewertung dar. Automatisierte Tests erfassen nur einen Teil der WCAG-2.1-AA-Erfolgskriterien; eine vollständige Bewertung erfordert manuelle Tests und Tests mit assistiven Technologien. Für Fragen zu Ihren Pflichten nach dem European Accessibility Act oder seinen nationalen Umsetzungen (BFSG, BGStG) wenden Sie sich an eine Rechtsanwältin oder einen Rechtsanwalt.