Grüner Kreis. Große Zahl. 100 Punkte.

Auf den ersten Blick sieht ein perfekter Lighthouse Accessibility Score ziemlich eindeutig aus:

Die Website ist barrierefrei.

Leider ist es nicht ganz so einfach.

Google Lighthouse ist ein hervorragendes Werkzeug, um bestimmte technische Probleme einer Website schnell aufzuspüren. Gerade für WordPress-Websites, Online-Shops und kleinere Unternehmensseiten ist es einer der einfachsten Einstiege in das Thema Barrierefreiheit.

Aber der Accessibility Score wird häufig falsch interpretiert.

Ein Wert von 100 bedeutet nicht automatisch, dass ein Nutzer mit Screenreader problemlos durch die Website kommt.

95 Punkte bedeuten nicht, dass die Website zu 95 Prozent barrierefrei ist.

Und 80 Punkte bedeuten nicht zwangsläufig, dass die Seite schlechter nutzbar ist als eine andere Seite mit 90 Punkten.

Der Score ist vielmehr das Ergebnis einer bestimmten Auswahl automatisierter Tests.

Genau deshalb lohnt sich ein genauer Blick darauf, was Lighthouse wirklich prüft – und vor allem, was es nicht prüfen kann.

Was ist Google Lighthouse?

Lighthouse ist ein Analysewerkzeug von Google, das direkt in Chrome verfügbar ist und verschiedene Bereiche einer Website untersuchen kann.

Dazu gehören unter anderem:

• Performance
• Accessibility
• Best Practices
• SEO

Für das Thema Barrierefreiheit interessiert uns der Bereich:

Accessibility

Lighthouse lädt die aktuelle Seite, analysiert verschiedene technische Eigenschaften und erstellt anschließend einen Bericht.

Am Ende erscheint ein Score zwischen 0 und 100.

Typischerweise werden die Ergebnisse farblich dargestellt.

Hohe Werte erscheinen grün.

Mittlere Werte orange.

Niedrige Werte rot.

Das macht das Ergebnis sehr leicht verständlich.

Vielleicht sogar etwas zu leicht.

Denn eine einzige Zahl kann dazu verleiten, ein ziemlich komplexes Thema stark zu vereinfachen.

Wie wird der Lighthouse Accessibility Score berechnet?

Der Accessibility Score ist kein einfacher Prozentsatz gefundener und nicht gefundener Fehler.

Lighthouse verwendet verschiedene automatisierte Prüfungen.

Diese Prüfungen haben unterschiedliche Gewichtungen.

Einige Fehler wirken sich stärker auf die Gesamtbewertung aus als andere.

Das bedeutet:

Zwei fehlgeschlagene Prüfungen können den Score stärker reduzieren als fünf andere.

Die Gewichtung orientiert sich daran, wie groß die mögliche Auswirkung eines Problems auf Nutzer sein kann.

Einzelne Prüfungen sind häufig Pass oder Fail

Ein wichtiger Punkt:

Lighthouse bewertet viele Accessibility-Audits nicht nach dem Prinzip:

„Fast richtig.“

Angenommen, deine Website besitzt zehn Buttons.

Neun davon haben einen verständlichen zugänglichen Namen.

Ein Button besitzt keinen.

Dann kann die entsprechende Prüfung trotzdem komplett als nicht bestanden gelten.

Du bekommst für diese Prüfung nicht automatisch 90 Prozent.

Das erklärt, warum manchmal die Korrektur eines einzigen Elements den Lighthouse Score deutlich verbessert.

Welche Dinge prüft Lighthouse?

Die genaue Liste kann sich mit neuen Lighthouse-Versionen verändern.

Typische Prüfbereiche sind jedoch unter anderem:

• Alt-Attribute bei Bildern
• zugängliche Namen für Buttons
• zugängliche Namen für Links
• Formularbeschriftungen
• Dokumentensprache
• ARIA-Verwendung
• Überschriftenstruktur
• Farbkontraste
• Seitentitel
• Frames und eingebettete Inhalte
• bestimmte Tabellenstrukturen
• fokussierbare Elemente
• semantische Strukturen

Damit findet Lighthouse tatsächlich viele wichtige technische Probleme.

Beispiel: Bild ohne Alt-Attribut

Du hast auf einer Produktseite ein Bild:

wanderschuh.jpg

Aber es wurde kein Alternativtext hinterlegt.

Lighthouse kann das erkennen.

Das ist hilfreich.

Was Lighthouse aber nicht zuverlässig beurteilen kann:

Ob ein vorhandener Alt-Text wirklich gut ist.

Alt-Text:

„Produktbild“

Technisch vorhanden.

Für den Nutzer wenig hilfreich.

Das ist bereits ein gutes Beispiel dafür, warum ein hoher Score nicht automatisch gute Barrierefreiheit bedeutet.

Beispiel: Button ohne zugänglichen Namen

Nehmen wir einen Warenkorb-Button.

Optisch wird nur ein Warenkorb-Symbol angezeigt.

Ein sehender Nutzer versteht:

Warenkorb.

Technisch besitzt der Button aber keinen zugänglichen Namen.

Ein Screenreader sagt möglicherweise nur:

„Button.“

Lighthouse kann solche Probleme erkennen.

Das ist eine Stärke des Tools.

Nachdem du dem Button einen zugänglichen Namen gegeben hast, kann die Prüfung bestehen.

Aber auch hier bleibt eine menschliche Frage:

Ist der Name tatsächlich verständlich?

„Cart-Icon 3“

wäre technisch vielleicht vorhanden, aber immer noch keine gute Nutzerinformation.

Beispiel: Formularfelder ohne Label

Ein Kontaktformular besitzt:

• Name
• E-Mail
• Nachricht

Optisch sieht alles gut aus.

Die Feldnamen werden allerdings nur über Platzhalter dargestellt.

Lighthouse kann bestimmte fehlende oder nicht richtig zugeordnete Labels erkennen.

Das ist besonders nützlich, weil solche Probleme mit bloßem Auge kaum auffallen.

Für einen Screenreader kann ein schlecht aufgebautes Formular dagegen erheblich schwieriger sein.

Beispiel: Farbkontrast

Auch Kontrastprobleme gehören zu den bekanntesten Lighthouse-Hinweisen.

Zum Beispiel:

hellgrauer Text auf weißem Hintergrund.

Lighthouse kann bei vielen Texten berechnen, ob der Kontrast bestimmte Anforderungen erfüllt.

Das ist praktisch.

Allerdings werden auch hier nicht alle denkbaren Situationen automatisch perfekt erfasst.

Besonders komplizierte Hintergründe, Bilder, Hover-Zustände oder dynamische Komponenten können zusätzliche manuelle Prüfung benötigen.

Ist ein Score von 100 gleichbedeutend mit barrierefrei?

Nein.

Das ist die wichtigste Aussage des gesamten Artikels.

Lighthouse 100 bedeutet nicht automatisch: vollständig barrierefreie Website.

Es bedeutet vereinfacht:

Alle für den Score relevanten automatisierten Prüfungen, die Lighthouse auf dieser Seite durchführen konnte, wurden bestanden.

Das ist etwas völlig anderes.

Beispiel

Eine Website erreicht:

Accessibility Score: 100

Trotzdem könnte Folgendes passieren:

Der Nutzer öffnet das Hauptmenü mit der Tastatur.

Das Dropdown erscheint.

Dann kann er nicht mehr heraus navigieren.

Lighthouse kann je nach konkreter Umsetzung möglicherweise keinen eindeutigen automatisierten Fehler erkennen.

Für einen echten Tastaturnutzer ist das Menü trotzdem praktisch unbenutzbar.

Noch ein Beispiel

Ein Formular besitzt technisch korrekte Labels.

Lighthouse:

Bestanden.

Der Nutzer gibt eine falsche E-Mail-Adresse ein.

Fehlermeldung:

„Error 124.“

Technisch kann trotzdem vieles korrekt aufgebaut sein.

Für einen echten Nutzer ist die Meldung schlecht.

Lighthouse kann nicht zuverlässig beurteilen, ob der Text verständlich formuliert ist.

Ein Lighthouse Score ist keine Prozentangabe der Barrierefreiheit

Dieser Punkt wird besonders häufig falsch verstanden.

Angenommen, Lighthouse zeigt:

94

Das bedeutet nicht:

Die Website ist zu 94 Prozent barrierefrei.

Es bedeutet:

Die gewichteten automatischen Prüfungen ergeben einen Score von 94.

Das ist ein großer Unterschied.

Warum Prozentangaben problematisch sind

Stell dir zwei Websites vor.

Website A

Score:

95

Problem:

Checkout-Zahlungsart kann nicht mit Tastatur ausgewählt werden.

Website B

Score:

88

Probleme:

Mehrere Überschriften sind technisch nicht optimal aufgebaut.

Welche Website ist für einen Tastaturnutzer besser?

Vielleicht Website B.

Obwohl ihr Score niedriger ist.

Denn Website A besitzt möglicherweise eine einzelne Barriere, die den kompletten Kauf verhindert.

Genau deshalb sollte man nie nur auf die Zahl schauen.

Warum erreicht eine schlechte Website manchmal einen hohen Score?

Das überrascht viele.

Eine Website kann sich im Alltag schlecht bedienen lassen und trotzdem einen relativ guten Lighthouse Score erhalten.

Der Grund ist einfach:

Lighthouse kann nur automatisch testbare Probleme bewerten.

Viele Accessibility-Fragen brauchen menschliches Urteilsvermögen.

Beispielsweise:

Ist der Linktext verständlich?

Ist die Tab-Reihenfolge logisch?

Ist ein Alt-Text sinnvoll?

Ist eine Fehlermeldung hilfreich?

Ist eine Überschrift inhaltlich korrekt eingesetzt?

Ist der Checkout nachvollziehbar?

Ist ein Popup störend?

Ist die Sprache verständlich?

Das kann ein automatischer Scanner nicht vollständig entscheiden.

Was bedeutet ein niedriger Lighthouse Score?

Ein niedriger Score sollte trotzdem ernst genommen werden.

Denn wenn Lighthouse bereits automatisch viele Probleme findet, gibt es wahrscheinlich tatsächlich technische Baustellen.

Typische Beispiele:

• viele Bilder ohne Alt-Attribute
• Buttons ohne zugängliche Namen
• Formularfelder ohne Labels
• schlechte Kontraste
• fehlerhafte ARIA-Verwendung
• fehlende Dokumentensprache

Das sind keine rein theoretischen Probleme.

Viele davon können echte Nutzer direkt betreffen.

Ein niedriger Score ist deshalb ein guter Anlass, genauer hinzusehen.

Was bedeutet ein hoher Score?

Ein hoher Wert ist grundsätzlich positiv.

Wenn eine Website 95 oder 100 Punkte erreicht, bedeutet das:

Viele automatisch erkennbare technische Grundlagen sind wahrscheinlich ordentlich umgesetzt.

Das ist gut.

Nur sollte man daraus nicht die Schlussfolgerung ziehen:

Fertig.

Besser:

Die automatischen Basisprüfungen sehen gut aus. Jetzt folgt der manuelle Test.

Warum manche Lighthouse-Prüfungen stärker gewichtet werden

Nicht jeder Fehler hat dieselben Auswirkungen.

Ein fehlender Alt-Text kann beispielsweise für einen blinden Nutzer eine wichtige Produktinformation vollständig unzugänglich machen.

Ein Button ohne zugänglichen Namen kann eine Funktion unverständlich machen.

Ein Formularfeld ohne Label kann verhindern, dass der Nutzer weiß, welche Information eingetragen werden soll.

Solche Probleme sind besonders relevant.

Deshalb werden Audits unterschiedlich gewichtet.

Das erklärt auch, weshalb eine einzelne Korrektur manchmal mehrere Punkte bringen kann.

Sollte man versuchen, unbedingt 100 Punkte zu erreichen?

Grundsätzlich spricht nichts dagegen.

Wenn Lighthouse technische Fehler meldet, sollte man sie prüfen und möglichst beheben.

Ein Score von 100 kann ein schönes Ziel sein.

Das Problem entsteht erst, wenn daraus das eigentliche Ziel wird.

Das falsche Ziel

„Wir brauchen 100 Punkte.“

Das bessere Ziel

„Unsere Website soll für möglichst viele Menschen gut bedienbar sein.“

Lighthouse ist dafür ein Werkzeug.

Nicht der Zweck.

Der typische Lighthouse-Fehler bei Agenturen

Manchmal sieht ein Prüfprozess so aus:

Website fertig.

Lighthouse öffnen.

Accessibility:

Screenshot erstellen.

Dem Kunden schreiben:

„Website ist barrierefrei.“

Das ist fachlich problematisch.

Ein Lighthouse-Bericht kann ein guter Bestandteil einer Prüfung sein.

Er ist aber kein vollständiger Accessibility-Test.

Wenn ein Kunde ausdrücklich eine BFSG- oder WCAG-Prüfung erwartet, reicht ein einzelner automatischer Lighthouse-Scan nicht aus.

Kann Lighthouse eine WCAG-Konformität bestätigen?

Nein.

Lighthouse testet verschiedene Punkte, die mit Accessibility-Standards zusammenhängen.

Ein bestandener Lighthouse-Test bedeutet aber nicht automatisch, dass sämtliche relevanten WCAG-Erfolgskriterien erfüllt sind.

WCAG-Konformität bezieht sich auf deutlich mehr als eine Auswahl automatisierbarer Prüfungen.

Dazu gehören auch manuelle Bewertungen.

Deshalb ist ein Lighthouse Score kein WCAG-Zertifikat.

Kann Lighthouse bestätigen, dass eine Website BFSG-konform ist?

Auch hier lautet die Antwort:

Nein.

Lighthouse kann technische Hinweise liefern, die bei der Verbesserung einer Website helfen.

Aber das BFSG ist eine rechtliche Anforderung und lässt sich nicht über eine einzelne Chrome-Zahl bestätigen.

Ein Score von 100 bedeutet nicht:

BFSG erfüllt.

Und ein Score von 92 bedeutet auch nicht automatisch:

BFSG verletzt.

Die rechtliche und technische Gesamtprüfung ist deutlich umfassender.

Welche Probleme findet Lighthouse besonders gut?

Lighthouse ist stark bei technischen Fehlern, die sich eindeutig erkennen lassen.

Dazu gehören beispielsweise:

Fehlende Alt-Attribute

Das Tool kann erkennen, ob entsprechende Attribute fehlen.

Formularlabels

Technische Zuordnungen können überprüft werden.

Buttons und Links

Elemente ohne zugängliche Namen können gefunden werden.

ARIA-Probleme

Bestimmte falsche ARIA-Verwendungen werden erkannt.

Sprache

Fehlende oder ungültige Sprachangaben lassen sich technisch prüfen.

Kontrast

Viele Kontrastprobleme können automatisch berechnet werden.

Dokumentstruktur

Bestimmte semantische Probleme können erkannt werden.

Gerade für Entwickler ist das sehr wertvoll.

Welche Probleme kann Lighthouse nur eingeschränkt prüfen?

Hier wird es interessanter.

Alt-Text-Qualität

Lighthouse erkennt:

Alt-Text vorhanden.

Aber nicht zuverlässig:

Ist er sinnvoll?

Beispiel:

„bild-final-neu-2.jpg“

kann trotzdem als Alt-Text eingetragen sein.

Verständlichkeit von Links

Lighthouse kann bestimmte technische Linkprobleme erkennen.

Aber:

„Mehr“

kann je nach Kontext trotzdem ein schlechter Linktext sein.

Fehlermeldungen

Technische Verknüpfungen lassen sich teilweise prüfen.

Aber nicht:

Ist:

„Ungültige Eingabe“

für den Nutzer hilfreich?

Navigation

Technische Eigenschaften können untersucht werden.

Aber eine komplett verwirrende Reihenfolge erfordert oft einen Praxistest.

Screenreader-Erfahrung

Lighthouse kann Accessibility-Informationen analysieren.

Es simuliert aber nicht vollständig, wie ein Mensch mit Screenreader die Seite erlebt.

Was prüft Lighthouse gar nicht zuverlässig?

Hier befinden sich einige besonders wichtige Themen.

Kann der komplette Shop ohne Maus bedient werden?

Das musst du selbst ausprobieren.

Ist der Tastaturfokus immer logisch?

Manuelle Prüfung.

Bleibt man in einem Popup hängen?

Manueller Tastaturtest.

Ist eine Produktbeschreibung verständlich?

Menschliche Bewertung.

Vermittelt eine Infografik alle Informationen auch textlich?

Manuelle Prüfung.

Funktioniert ein Zahlungsanbieter mit Screenreader?

Praktischer Test.

Kann ein Nutzer eine Bestellung vollständig abschließen?

End-to-End-Test.

Genau deshalb braucht Accessibility immer mehrere Prüfmethoden.

Warum zeigt Lighthouse manchmal unterschiedliche Scores?

Vielleicht hast du dieselbe Seite mehrfach getestet und einmal:

94

und später:

97

erhalten.

Beim Accessibility Score sind die Schwankungen normalerweise weniger typisch als bei Performance-Werten.

Trotzdem können sich Ergebnisse verändern.

Zum Beispiel durch:

• dynamische Inhalte
• Cookie-Banner
• Popups
• eingebettete Drittanbieter
• unterschiedliche Seitenzustände
• nachgeladene Elemente
• A/B-Tests
• eingeloggte und ausgeloggte Nutzer

Deshalb sollte immer geprüft werden, welcher Zustand der Seite tatsächlich getestet wurde.

Cookie-Banner kann den Test beeinflussen

Ein gutes Beispiel:

Du hast Cookies bereits akzeptiert.

Lighthouse testet die Website ohne Banner.

Ergebnis:

Ein neuer Besucher öffnet die Seite.

Cookie-Banner erscheint.

Das Banner besitzt:

• keinen sichtbaren Fokus,
• schlecht beschriftete Schalter,
• unzugängliche Buttons.

Diese Probleme wurden in deinem vorherigen Test gar nicht berücksichtigt, weil der Banner nicht sichtbar war.

Deshalb solltest du wichtige Zustände separat testen.

Online-Shop: Nicht nur die Startseite testen

Ein weiterer klassischer Fehler:

Startseite mit Lighthouse testen.

Accessibility Score:

Fertig.

Bei einem Online-Shop reicht das nicht.

Denn die wichtigsten interaktiven Bereiche liegen möglicherweise auf ganz anderen Seiten.

Teste mindestens:

• Startseite
• Kategorie
• Produktseite
• Warenkorb
• Checkout
• Kundenkonto

Wenn Produktvarianten ein zusätzliches Plugin verwenden, sollte eine entsprechende Produktseite ebenfalls geprüft werden.

Kontaktformulare separat testen

Auch Unternehmenswebsites brauchen mehrere Tests.

Die Startseite kann technisch hervorragend sein.

Im Kontaktformular fehlen dagegen Labels.

Oder das Captcha ist nicht bedienbar.

Oder die Fehlermeldungen werden nicht korrekt ausgegeben.

Deshalb sollte mindestens eine Seite mit Formular separat getestet werden.

Wie starte ich Lighthouse?

Der einfachste Weg führt über Chrome.

Öffne die gewünschte Website.

Dann:

1. Rechtsklick auf die Seite.
2. „Untersuchen“ öffnen.
3. Den Bereich „Lighthouse“ auswählen.
4. Accessibility aktivieren.
5. Analyse starten.

Anschließend bekommst du einen Bericht.

Nicht nur auf die Zahl schauen

Nach dem Test sollte dein erster Blick nicht ausschließlich auf:

Accessibility: 92

gehen.

Scrolle weiter.

Schau dir die einzelnen fehlgeschlagenen Audits an.

Frage:

Welche konkrete Stelle ist betroffen?

Wie wirkt sich das auf einen Nutzer aus?

Wie kann ich sie beheben?

Der Detailbericht ist eigentlich wertvoller als die große Zahl oben.

Unterschied zwischen Fehlern und manuellen Prüfungen

Im Lighthouse-Bericht findest du neben automatisch überprüfbaren Problemen teilweise auch Hinweise auf Punkte, die man zusätzlich manuell kontrollieren sollte.

Diese können nicht automatisch als bestanden gewertet werden.

Und genau das ist wichtig.

Ein Tool kann nicht einfach behaupten:

„Tab-Reihenfolge ist sinnvoll.“

ohne einen tatsächlichen Nutzungskontext zu verstehen.

Manuelle Prüfungen sollten deshalb nicht ignoriert werden, nur weil sie den Score nicht verändern.

Ein Problem ohne Score-Einfluss kann trotzdem wichtig sein

Das ist eine der größten Fallen des Systems.

Wenn eine Prüfung keine Punkte beeinflusst, wirkt sie auf den ersten Blick unwichtig.

Das muss aber überhaupt nicht stimmen.

Manuelle Checks können für echte Nutzer enorm relevant sein.

Ein Problem kann also:

0 Punkte Einfluss auf Lighthouse

aber gleichzeitig:

großen Einfluss auf die Bedienbarkeit

haben.

Der Score darf deshalb niemals über die Priorität eines Problems entscheiden.

Wie sollte man Lighthouse sinnvoll verwenden?

Ich würde Lighthouse in drei Phasen einsetzen.

Phase 1: Entwicklung

Schon während der Erstellung.

Neue Seite bauen.

Lighthouse starten.

Technische Fehler früh beheben.

Das ist viel einfacher als am Ende 50 Seiten nachträglich zu korrigieren.

Phase 2: Vor Veröffentlichung

Wichtige Seitentypen testen.

Startseite.

Formular.

Produktseite.

Checkout.

Phase 3: Nach Änderungen

Theme aktualisiert?

Plugin installiert?

Checkout umgebaut?

Neues Cookie-Tool?

Dann erneut testen.

So wird Lighthouse Teil der Qualitätssicherung.

Lighthouse und WordPress

Gerade bei WordPress kann Lighthouse sehr hilfreich sein.

Denn viele technische Probleme entstehen nicht direkt im eigenen Inhalt, sondern durch:

• Theme
• Pagebuilder
• Plugins
• Navigation
• Formulare
• Cookie-Tools
• WooCommerce-Erweiterungen

Du siehst im Backend vielleicht keinen Fehler.

Im Frontend erzeugt ein Plugin trotzdem einen namenlosen Button.

Lighthouse analysiert die tatsächlich ausgegebene Website.

Das macht den Test besonders wertvoll.

Lighthouse und Divi, Elementor oder andere Pagebuilder

Pagebuilder erzeugen komplexes HTML.

Das ist nicht automatisch schlecht.

Aber bei individuellen Modulen können Accessibility-Probleme entstehen.

Typische Bereiche:

• Akkordeons
• Tabs
• Slider
• Popups
• Menüs
• Icon-Buttons
• Formulare

Lighthouse kann einige technische Fehler finden.

Danach sollte allerdings immer ein Tastaturtest folgen.

Lighthouse bei WooCommerce

Bei WooCommerce solltest du verschiedene Elemente separat ansehen.

Produktseite

Alt-Texte.

Varianten.

Buttons.

Kontrast.

Warenkorb

Mengenfelder.

Entfernen-Buttons.

Gutschein.

Checkout

Formularlabels.

Zahlungsarten.

Fehlermeldungen.

Kundenkonto

Login.

Passwort.

Downloads.

Eine perfekte Startseite sagt nichts darüber aus, wie gut der Checkout funktioniert.

Was ist besser: Lighthouse oder WAVE?

Die Frage muss eigentlich nicht gestellt werden.

Nutze beide.

Lighthouse eignet sich hervorragend für einen schnellen automatischen Test.

WAVE zeigt Probleme visuell direkt auf der Seite.

Dadurch ergänzen sich die Tools.

Ein einfacher Workflow:

Lighthouse.

Dann WAVE.

Danach Tastaturtest.

Damit findest du bereits deutlich mehr als mit einem einzelnen Tool.

Was ist besser: Lighthouse oder axe?

Auch hier:

Warum entscheiden?

Lighthouse verwendet automatisierte Accessibility-Prüfungen und stellt sie sehr einfach dar.

axe DevTools bietet Entwicklern zusätzliche technische Möglichkeiten.

Für einen schnellen Websitecheck:

Lighthouse.

Für tiefergehende technische Fehlersuche:

axe zusätzlich verwenden.

Mein einfacher Accessibility-Workflow

Wenn ich eine normale Website grob prüfen würde, sähe mein kostenloser Ablauf so aus:

1. Lighthouse

Technische Basisprobleme finden.

2. WAVE oder axe

Ergebnisse ergänzen und konkrete Elemente untersuchen.

3. Tastatur

Maus weglegen.

Navigation, Formulare und Buttons testen.

4. Zoom

Website auf 200 Prozent vergrößern.

5. Screenreader

Mindestens wichtige Bereiche anhören.

6. Mobile Ansicht

Smartphone verwenden.

Erst die Kombination ergibt ein realistisches Bild.

Beispiel: Lighthouse 100 und trotzdem schlechte Website

Nehmen wir einen fiktiven Online-Shop.

Lighthouse:

100 Accessibility

Perfekt?

Wir testen manuell.

Navigation

Dropdown öffnet sich per Tastatur.

Gut.

Aber Escape schließt es nicht.

Produktvarianten

Farben sind nur als Kreise dargestellt.

Screenreader bekommt keine verständlichen Farbnamen.

Checkout

Fehlermeldung lautet:

„Invalid data.“

Zahlungsanbieter

Popup öffnet sich.

Fokus bleibt dahinter im Shop.

Ergebnis

Lighthouse:

Praktische Nutzung:

mehrere Probleme.

Genau deshalb ist der Score nur ein Teil des Gesamtbilds.

Beispiel: Lighthouse 85 und trotzdem vergleichsweise gute Bedienbarkeit

Ein anderer Shop erreicht nur:

Warum?

Mehrere Bilder besitzen fehlende Alt-Texte.

Eine Überschriftenstruktur enthält Fehler.

Einige Kontrastprobleme bestehen.

Diese Probleme sollten behoben werden.

Trotzdem funktioniert:

• Navigation mit Tastatur,
• Checkout,
• Zahlungsanbieter,
• Fokussteuerung,
• Screenreader-Struktur

vielleicht sehr gut.

Der niedrigere Score bedeutet also nicht automatisch, dass jede Nutzung schlechter ist.

Beide Arten von Problemen sind relevant.

Sie haben nur unterschiedliche Auswirkungen.

Welcher Score ist gut?

Natürlich möchte jeder eine konkrete Zahl.

Eine einfache Orientierung könnte lauten:

Je höher, desto besser – innerhalb dessen, was Lighthouse tatsächlich misst.

Ein Wert von:

100

ist besser als 70, wenn die getestete Seite und Bedingungen identisch sind und die Verbesserungen echte Accessibility-Probleme beheben.

Aber es gibt keine magische Grenze:

Ab 95 ist eine Website barrierefrei.

So funktioniert das Thema nicht.

Der Score sollte als technischer Qualitätsindikator betrachtet werden.

Nicht als Zertifizierung.

Sollte ich einen Lighthouse-Score auf meiner Website veröffentlichen?

Das würde ich eher vorsichtig betrachten.

Ein Screenshot mit:

Accessibility 100

kann schnell den Eindruck vermitteln:

Unsere Website ist vollständig barrierefrei.

Das lässt sich allein aus Lighthouse nicht ableiten.

Besser wäre, falls du überhaupt darüber kommunizieren möchtest:

„Die Website wird regelmäßig mit automatisierten und manuellen Accessibility-Tests überprüft.“

Das beschreibt den Prozess besser als eine einzelne Zahl.

Kann Lighthouse ein professionelles Audit ersetzen?

Nein.

Für einen ersten Selbsttest:

sehr gut.

Für laufende Entwicklung:

sehr gut.

Für das Finden technischer Fehler:

sehr gut.

Für eine vollständige fachliche oder rechtliche Konformitätsbewertung:

nicht ausreichend.

Ein umfassender Test berücksichtigt zusätzlich:

• manuelle WCAG-Prüfung
• Tastaturbedienung
• Screenreader
• Vergrößerung
• mobile Nutzung
• verschiedene Zustände
• echte Nutzerprozesse
• gegebenenfalls Tests mit Menschen mit Behinderungen

Der beste Lighthouse-Test ist der erste Schritt, nicht der letzte

Genau so würde ich den Score betrachten.

Nicht:

100 erreicht – erledigt.

Sondern:

Automatische Fehler beseitigt – jetzt weitertesten.

Das macht Lighthouse nicht weniger wertvoll.

Im Gegenteil.

Das Tool ist hervorragend für genau die Aufgabe, für die es gedacht ist.

Problematisch wird es erst, wenn man ihm mehr Bedeutung gibt, als der Score tatsächlich besitzt.

Praktische Checkliste nach einem Lighthouse-Test

Du hast einen guten Accessibility Score erreicht?

Dann teste zusätzlich:

• Kann die Website komplett mit Tastatur bedient werden?
• Ist der Fokus jederzeit sichtbar?
• Ist die Tab-Reihenfolge logisch?
• Lassen sich Menüs öffnen und schließen?
• Funktionieren Popups ohne Maus?
• Sind Alt-Texte wirklich sinnvoll?
• Sind Linktexte verständlich?
• Sind Formularfehler konkret beschrieben?
• Bleiben Formulardaten nach Fehlern erhalten?
• Funktioniert die Seite bei 200 Prozent Zoom?
• Funktioniert der Shop auf dem Smartphone?
• Ist das Cookie-Banner zugänglich?
• Funktioniert der Checkout?
• Funktionieren externe Zahlungsanbieter?
• Ist die Screenreader-Ausgabe verständlich?

Wenn diese Punkte ebenfalls gut funktionieren, wird der Lighthouse Score deutlich aussagekräftiger.

Ein einfacher 15-Minuten-Test nach Lighthouse

Wenn du wenig Zeit hast:

Minute 1–3

Lighthouse durchführen.

Minute 3–6

Fehler im Bericht ansehen.

Minute 6–10

Maus weglegen und die Seite mit Tab bedienen.

Minute 10–12

Browser auf 200 Prozent Zoom stellen.

Minute 12–15

Formular oder wichtige Funktion bewusst falsch bedienen und Fehlermeldungen prüfen.

Damit bekommst du bereits ein wesentlich realistischeres Bild als durch den Score allein.

Fazit: Lighthouse misst technische Hinweise – nicht die gesamte Nutzererfahrung

Der Google Lighthouse Accessibility Score ist ein sehr gutes Werkzeug.

Er ist:

• kostenlos,
• schnell,
• direkt in Chrome verfügbar,
• leicht verständlich,
• hilfreich bei technischen Fehlern.

Das macht ihn zu einem perfekten Einstieg.

Aber genau dort liegt seine Rolle:

Einstieg.

Ein Wert von 100 sagt:

Die für den Score relevanten automatisierten Prüfungen wurden auf dieser Seite bestanden.

Er sagt nicht:

Jeder Mensch kann diese Website problemlos nutzen.

Er sagt auch nicht:

Die Website erfüllt automatisch sämtliche Anforderungen von WCAG oder BFSG.

Mein praktischer Rat lautet deshalb:

Freu dich über einen hohen Score – aber hör dort nicht auf.

Behebe alle gefundenen Lighthouse-Probleme.

Lege danach die Maus weg.

Teste Formulare.

Öffne Menüs.

Provoziere Fehler.

Vergrößere die Seite.

Teste wichtige Prozesse mit Screenreader.

Genau dann wird aus:

„Lighthouse sagt 100“

eine viel interessantere Aussage:

„Unsere Website funktioniert auch in der Praxis deutlich besser für unterschiedliche Nutzer.“

Und genau darum sollte es beim Thema Barrierefreiheit letztendlich gehen.

Hinweis: Lighthouse bietet eine technische Orientierung und ersetzt weder eine vollständige fachliche Barrierefreiheitsprüfung noch eine individuelle rechtliche Bewertung.