Google Lighthouse Barrierefreiheit: Was der Score bedeutet und was er nicht zeigt

Was ist Google Lighthouse?

Google Lighthouse ist ein kostenloses Open-Source-Tool von Google, das Webseiten in fünf Kategorien analysiert: Performance, Accessibility, Best Practices, SEO und Progressive Web App. Es ist direkt in Chrome DevTools eingebaut, als CLI verfügbar und über PageSpeed Insights auch online nutzbar.

Für Barrierefreiheit nutzt Lighthouse die axe-core-Bibliothek von Deque Systems – dieselbe Engine, die auch in axe DevTools und vielen anderen Accessibility-Tools steckt. Lighthouse prüft rund 50 automatisierbare Regeln und gibt einen Score von 0 bis 100.

Seit der Einführung des BFSG (Barrierefreiheitsstärkungsgesetz) im Juni 2025 ist Lighthouse für viele Website-Betreiber der erste Anlaufpunkt, um den Stand der eigenen Barrierefreiheit einzuschätzen. Doch der Accessibility-Score allein reicht nicht aus – weder technisch noch rechtlich. In diesem Artikel erfährst du, was Lighthouse wirklich testet, wo seine Grenzen liegen, wie du es optimal einsetzt und welche Ergänzungen du brauchst.

Hinweis: Dieser Artikel dient der technischen Orientierung. Ein Lighthouse-Score ersetzt weder eine rechtliche Bewertung nach dem BFSG noch ein vollständiges WCAG-Audit. Im Zweifel ziehe Fachleute hinzu.

Den Lighthouse Accessibility Score verstehen (0–100)

Der Score berechnet sich aus dem gewichteten Anteil bestandener Prüfungen. Nicht jede Regel wiegt gleich – kritische Fehler wie fehlende Alt-Texte (WCAG SC 1.1.1) haben ein höheres Gewicht als Warnungen wie fehlende Meta-Beschreibungen.

Score-Bereiche und ihre Bedeutung:

• 90–100 (grün): Gut – die automatisch prüfbaren Kriterien sind größtenteils erfüllt
• 50–89 (orange): Verbesserungsbedarf – es gibt relevante Barrieren
• 0–49 (rot): Kritisch – grundlegende Barrierefreiheits-Probleme

Wichtig: Ein Score von 100 bedeutet nicht, dass deine Seite barrierefrei ist. Er bedeutet nur, dass alle automatisch testbaren Kriterien bestanden wurden – und das sind laut Deque Research nur rund 30 % aller WCAG-2.1-Kriterien.

Score-Schwankungen verstehen

Lighthouse-Scores können zwischen einzelnen Durchläufen um 5–10 Punkte schwanken. Das liegt an mehreren Faktoren:

• Netzwerk-Timing: Dynamisch geladene Inhalte (z. B. per JavaScript eingefügte Elemente) werden je nach Ladezeit unterschiedlich erfasst
• A/B-Tests und personalisierte Inhalte: Wenn deine Seite verschiedene Versionen ausspielt, variiert auch der Score
• Cookie-Banner und Overlays: Je nach Zustand (akzeptiert/nicht akzeptiert) können unterschiedliche Elemente im DOM sein

Tipp: Führe mindestens drei Lighthouse-Runs durch und orientiere dich am Median-Wert. In der CLI erreichst du das mit dem Flag --n=3.

Was Lighthouse prüft: Die axe-core-Regeln im Detail

Lighthouse testet gegen eine Auswahl von WCAG-2.1-Kriterien auf Level A und AA. Die wichtigsten geprüften Bereiche:

• Bilder ohne Alt-Text (WCAG SC 1.1.1 – Nicht-Text-Inhalt)
• Farbkontraste (WCAG SC 1.4.3 – Kontrast Minimum) – prüft Text gegen Hintergrund auf 4,5:1 bzw. 3:1
• Formular-Labels (WCAG SC 1.3.1 – Info und Beziehungen) – erkennt Eingabefelder ohne zugeordnetes Label
• ARIA-Attribute (WCAG SC 4.1.2 – Name, Rolle, Wert) – validiert korrekte ARIA-Rollen und -Werte
• Überschriften-Hierarchie (WCAG SC 1.3.1) – warnt bei übersprungenen Ebenen
• Sprach-Attribut (WCAG SC 3.1.1 – Sprache der Seite) – prüft ob lang gesetzt ist
• Link-Texte (WCAG SC 2.4.4 – Linkzweck im Kontext) – erkennt generische Texte wie „hier klicken“
• Tabindex-Werte (WCAG SC 2.4.3 – Fokus-Reihenfolge) – warnt bei tabindex > 0
• Doppelte IDs (WCAG SC 4.1.1 – Parsing) – IDs müssen eindeutig sein

Eine vollständige Liste aller axe-core-Regeln findest du in der axe-core-Dokumentation auf GitHub.

Wie Lighthouse die axe-core-Regeln gewichtet

Nicht jeder Fehler zählt gleich. Lighthouse kategorisiert die Ergebnisse in drei Stufen:

• Fehler (Failures): Definitiv vorhandene Barrieren – z. B. fehlende Alt-Texte, zu geringe Kontraste. Diese senken den Score direkt.
• Manuelle Prüfungen (Manual checks): Kriterien, die Lighthouse erkennt, aber nicht automatisch bewerten kann – z. B. „Die Seite hat eine logische Tab-Reihenfolge“. Sie beeinflussen den Score nicht, sind aber für die BFSG-Konformität relevant.
• Nicht zutreffend (Not applicable): Regeln, die für deine Seite nicht gelten – z. B. Video-bezogene Prüfungen auf einer Seite ohne Videos.

Innerhalb der Fehler haben kritische Verstöße wie fehlende Alt-Texte (WCAG SC 1.1.1) oder fehlende Formular-Labels (WCAG SC 1.3.1) ein höheres Gewicht als Warnungen wie übersprungene Überschriftenebenen. Die exakte Gewichtung ändert sich mit jeder Lighthouse-Version – die Tendenz bleibt aber stabil.

Was Lighthouse NICHT prüft – die blinden Flecken

Hier liegt das größte Missverständnis: Viele denken, ein Lighthouse-Score von 100 bedeutet volle Barrierefreiheit. Tatsächlich kann Lighthouse folgende Kriterien nicht automatisch testen:

• Logische Tab-Reihenfolge (WCAG SC 2.4.3) – Lighthouse prüft ob tabindex korrekt ist, aber nicht ob die Reihenfolge sinnvoll ist
• Tastatur-Fallen (WCAG SC 2.1.2) – ob Nutzer in Modals, Dropdowns oder Slidern „gefangen“ werden
• Screenreader-Kompatibilität – ob ARIA-Patterns korrekt umgesetzt sind und die Ausgabe verständlich ist
• Sinnvolle Alternativtexte – Lighthouse erkennt fehlende Alt-Texte, aber nicht ob „Bild1.jpg“ ein sinnvoller Text ist
• Verständliche Fehlermeldungen (WCAG SC 3.3.1, SC 3.3.3) – ob Fehler klar kommuniziert werden
• Animationen und Bewegung (WCAG SC 2.3.1 – Drei Blitze oder unter Schwellenwert) – problematisch für Epilepsie-Betroffene
• Zoom auf 200 % (WCAG SC 1.4.4 – Textgröße ändern) – ob Inhalte bei starker Vergrößerung noch nutzbar sind
• Kognitive Barrierefreiheit – ob Texte verständlich, Layouts konsistent und Prozesse vorhersehbar sind

Das bedeutet: Selbst mit einem perfekten Lighthouse-Score können 70 % der WCAG-Kriterien ungeprüft sein. Für eine vollständige Bewertung brauchst du zusätzlich manuelle Tests – mehr dazu in unserem Artikel DIY Barrierefreiheits-Audit.

Praxis-Beispiel: Was Lighthouse übersieht

Stell dir einen Online-Shop vor, dessen Lighthouse-Score bei 98 liegt. Klingt gut. Aber:

• Der Checkout hat eine Tastaturfalle im Dropdown für die Versandart – Nutzer können das Feld nicht verlassen (WCAG SC 2.1.2, Keine Tastaturfalle)
• Fehlermeldungen im Bestellformular sind nur rot gefärbt, nicht als Text beschrieben (WCAG SC 3.3.1, Fehlererkennung)
• Die Produktbilder haben Alt-Texte wie „Produktbild“ statt „Blaue Laufschuhe Nike Air Max, Größe 42“ – technisch vorhanden, inhaltlich wertlos
• Bei 200 % Zoom überlappt das Menü den Inhalt (WCAG SC 1.4.4, Textgröße ändern)

Keiner dieser Fehler taucht im Lighthouse-Report auf. Alle sind BFSG-relevant. Deshalb ist die Kombination aus automatischem Scan und manuellem Test unverzichtbar. Einen Überblick über alle verfügbaren Barrierefreiheits-Testing-Tools findest du in unserem Vergleichsartikel.

Lighthouse nutzen: 4 Wege zum Accessibility-Audit

1. Chrome DevTools (schnellster Weg)

Öffne deine Webseite in Chrome, drücke F12 (oder Rechtsklick → Untersuchen), wechsle zum Tab Lighthouse, wähle „Accessibility“ und klicke „Analyze page load“. In wenigen Sekunden siehst du deinen Score und alle gefundenen Probleme.

2. Lighthouse CLI (für Entwickler)

Installiere Lighthouse global via npm:

npm install -g lighthouse

Dann starte einen Audit:

lighthouse https://deine-seite.de --only-categories=accessibility --output=html --output-path=./report.html

Das erzeugt einen HTML-Report, den du im Browser öffnen und mit dem Team teilen kannst.

3. CI/CD-Integration (automatisiert)

Mit dem Paket @lhci/cli (Lighthouse CI) kannst du Accessibility-Checks in deine Build-Pipeline einbauen. Definiere einen Mindest-Score als Quality Gate:

lhci assert --preset=lighthouse:recommended --assert.categories.accessibility=0.9

So wird jedes Deployment automatisch blockiert, wenn der Accessibility-Score unter 90 fällt. Besonders wertvoll für Teams, die regelmäßig deployen.

4. PageSpeed Insights (ohne Installation)

Unter pagespeed.web.dev kannst du jede öffentliche URL analysieren – ohne etwas zu installieren. PageSpeed Insights nutzt Lighthouse im Hintergrund und zeigt den Accessibility-Score zusammen mit Performance-Daten.

Score verbessern: Die 10 häufigsten Lighthouse-Fehler und ihre Fixes

Diese Fehler tauchen in fast jedem Lighthouse-Audit auf. Hier die Lösungen:

1. Images do not have alt attributes – Ergänze beschreibende alt-Attribute. Für dekorative Bilder: alt="" (WCAG SC 1.1.1)
2. Background and foreground colors do not have sufficient contrast ratio – Erhöhe den Kontrast auf mindestens 4,5:1 für normalen Text (WCAG SC 1.4.3). Nutze Tools wie den Farbkontrast-Rechner
3. Form elements do not have associated labels – Verlinke jedes <input> mit einem <label for="..."> (WCAG SC 1.3.1)
4. Links do not have a discernible name – Ersetze leere Links oder Icon-Links durch beschreibenden Text oder aria-label (WCAG SC 2.4.4)
5. Document does not have a main landmark – Wickle deinen Hauptinhalt in <main> (WCAG SC 1.3.1)
6. Heading elements are not in sequentially-descending order – Korrigiere die Hierarchie: H1 → H2 → H3, keine Stufen überspringen (WCAG SC 1.3.1)
7. html element does not have a lang attribute – Setze <html lang="de"> (WCAG SC 3.1.1)
8. ARIA attributes do not match their roles – Überprüfe deine ARIA-Rollen und -Attribute auf Gültigkeit (WCAG SC 4.1.2)
9. Buttons do not have an accessible name – Ergänze Text oder aria-label für Icon-Buttons (WCAG SC 4.1.2)
10. Document does not have a meta viewport tag with width or initial-scale – Setze <meta name="viewport" content="width=device-width, initial-scale=1">

Diese 10 Fixes allein können deinen Score um 30–50 Punkte anheben. Die meisten sind in wenigen Minuten umgesetzt.

Systematisch vorgehen: Score-Verbesserung in 3 Schritten

Statt alle Fehler auf einmal anzugehen, empfehlen wir einen strukturierten Ansatz:

Schritt 1 – Kritische Fehler zuerst: Behebe alle Fehler mit hohem Gewicht (fehlende Alt-Texte, fehlende Labels, fehlende Landmarks). Diese bringen den größten Score-Sprung.

Schritt 2 – Kontraste und Struktur: Passe Farben an, korrigiere die Überschriften-Hierarchie und setze fehlende ARIA-Attribute. Nutze dafür unseren Artikel Farbkontraste prüfen und korrigieren als Anleitung.

Schritt 3 – Feinschliff: Beseitige Warnungen (doppelte IDs, tabindex-Werte, generische Link-Texte). Diese haben weniger Gewicht, runden aber den Score ab.

Nach jedem Schritt: erneuten Lighthouse-Run durchführen und den Fortschritt dokumentieren. So siehst du genau, welche Maßnahmen den größten Effekt hatten.

Lighthouse vs. axe DevTools vs. WAVE: Welches Tool für was?

Alle drei Tools nutzen axe-core als Basis, unterscheiden sich aber im Fokus und Funktionsumfang. Hier eine Übersicht für die Auswahl des richtigen Tools:

Google Lighthouse:

• Allgemeiner Web-Audit (Performance + SEO + Accessibility)
• Gut für schnelle Überprüfungen und CI/CD-Integration
• Testet ca. 50 axe-core-Regeln
• Kostenlos

axe DevTools (Deque):

• Spezialisiert auf Barrierefreiheit
• Mehr Regeln als Lighthouse (80+ in der Pro-Version)
• Guided Tests für manuelle Prüfungen
• Basis-Version kostenlos, Pro ab ca. 40 USD/Monat

WAVE (WebAIM):

• Zeigt Fehler visuell direkt auf der Seite an
• Sehr intuitiv für Nicht-Entwickler
• Erkennt auch strukturelle Probleme (Überschriften, Landmarks)
• Kostenlos als Browser-Extension

bf-check.de (BFSG-spezialisiert):

• Speziell auf deutsche BFSG-Anforderungen zugeschnitten
• Handlungsempfehlungen im deutschen Rechtskontext
• Bewertet Schwere der Verstöße nach BFSG-Relevanz
• Kostenloser Basis-Scan

Die beste Strategie: Nutze Lighthouse als schnellen automatischen Check, ergänze mit WAVE für visuelle Inspektion und verwende bf-check.de für die BFSG-spezifische Bewertung. Mehr zu allen verfügbaren Tools findest du in unserem Überblick: Barrierefreiheit testen – Tools im Vergleich.

Lighthouse im BFSG-Kontext: Was reicht – und was nicht

Das BFSG verweist auf die harmonisierte Norm EN 301 549, die wiederum WCAG 2.1 Level AA als Mindeststandard für Webinhalte definiert. Lighthouse deckt einen Teil dieser Kriterien ab – aber eben nur den automatisch testbaren Teil.

Für BFSG-Konformität brauchst du:

1. Lighthouse-Score von mindestens 90 (als Hygiene-Faktor)
2. Manuelle Prüfung der Tastatur-Navigation (WCAG SC 2.1.1, SC 2.1.2)
3. Screenreader-Test auf den wichtigsten Seiten
4. Prüfung der Zoom-Fähigkeit auf 200 % (WCAG SC 1.4.4)
5. Verständliche Fehlermeldungen in Formularen (WCAG SC 3.3.1, SC 3.3.3)
6. Dokumentation in einer Barrierefreiheitserklärung

Lighthouse ist also ein notwendiger, aber kein hinreichender Schritt zur BFSG-Konformität. Nutze es als Ausgangspunkt und ergänze mit manuellen Tests und einem strukturierten Audit.

Lighthouse-Ergebnisse richtig interpretieren und priorisieren

Nach einem Lighthouse-Run siehst du eine Liste von Fehlern, Warnungen und bestandenen Prüfungen. Hier die richtige Reihenfolge für die Abarbeitung:

1. Fehlende Alt-Texte und Labels – betreffen die meisten Nutzer mit Einschränkungen und haben das höchste Gewicht im Score
2. Kontrast-Fehler – betreffen ca. 8 % der Männer (Farbenfehlsichtigkeit) plus alle Nutzer bei Sonnenlicht oder auf schlechten Displays
3. ARIA-Fehler – können Screenreader verwirren und ganze Seitenbereiche unbrauchbar machen (WCAG SC 4.1.2)
4. Struktur-Warnungen – übersprungene Überschriften, fehlende Landmarks – weniger kritisch, aber leicht zu fixen
5. Manuelle Prüfungen – die items unter „Additional items to manually check“ sind für BFSG-Konformität genauso relevant wie die automatischen Fehler

Dokumentiere jeden Fix mit Datum und Lighthouse-Score vorher/nachher. So entsteht eine nachvollziehbare Historie, die auch bei einer möglichen Überprüfung hilfreich ist.

Lighthouse-Report mit dem Team teilen

Lighthouse bietet verschiedene Output-Formate, die sich für unterschiedliche Zielgruppen eignen:

• HTML-Report (--output=html): Visuell aufbereitet, ideal für Entscheider und nicht-technische Stakeholder
• JSON-Report (--output=json): Maschinenlesbar, ideal für die Integration in Dashboards oder CI/CD-Pipelines
• CSV-Export: Über die Chrome DevTools kannst du einzelne Tabellen kopieren – praktisch für die Übergabe an Entwickler als Ticket-Liste

In der CI/CD-Pipeline empfiehlt sich zusätzlich das Tool Lighthouse CI Server, das Reports über Zeit speichert und Score-Trends visualisiert. So erkennst du sofort, wenn ein Deployment die Barrierefreiheit verschlechtert.

Häufig gestellte Fragen