Google Lighthouse Accessibility: Score, Grenzen und richtige Nutzung

Der Lighthouse Accessibility Score ist die wohl bekannteste Barrierefreiheits-Metrik im Web. Er ist kostenlos, direkt in Chrome DevTools verfügbar und liefert innerhalb von Sekunden einen Zahlenwert. Genau darin liegt aber auch die Gefahr: Ein Score von 100 bedeutet nicht, dass eine Webseite barrierefrei ist. Lighthouse prüft nur das, was automatisiert testbar ist – und das sind weniger als die Hälfte aller WCAG-Kriterien.

Was prüft Lighthouse im Accessibility-Audit?

Der Lighthouse Accessibility Audit basiert auf einer Teilmenge der axe-core-Regeln. Geprüft werden unter anderem:

• Alt-Texte für Bilder
• Formular-Labels
• Farbkontraste (Text gegen Hintergrund)
• Dokumentsprache (lang-Attribut)
• Überschriftenstruktur (logische Reihenfolge)
• ARIA-Attribute (korrekte Werte und Verwendung)
• Link-Namen (nicht leer, nicht generisch)
• Tabindex-Werte (keine positiven Werte)
• Button-Namen
• Meta-Viewport (zoom nicht deaktiviert)

Insgesamt sind es etwa 40 Regeln. Jede Regel wird gewichtet – schwere Verstöße wie fehlende Alt-Texte oder Labels senken den Score stärker als leichtere wie suboptimale Überschriftenreihenfolge. Der Score wird als gewichteter Durchschnitt der bestandenen Checks berechnet.

Warum 100 Punkte nicht "barrierefrei" bedeutet

Ein Lighthouse Score von 100 bedeutet: Alle ~40 automatisierten Checks wurden bestanden. Das klingt gut, deckt aber nur einen Bruchteil der WCAG-2.1-Anforderungen ab. Nicht geprüft werden:

• Tastaturbedienbarkeit: Kann man alle Funktionen nur mit der Tastatur erreichen? Gibt es Fokus-Fallen?
• Inhaltliche Qualität: Sind Alt-Texte sinnvoll (nicht nur vorhanden)? Sind Link-Texte aussagekräftig?
• Logische Lesereihenfolge: Ergibt der Inhalt ohne CSS Sinn? Stimmt die visuelle mit der DOM-Reihenfolge überein?
• Interaktive Widgets: Funktionieren Custom-Dropdowns, Tabs und Modals mit Screenreadern?
• Zeitgesteuerte Inhalte: Können Nutzer Timeouts verlängern? Können Animationen pausiert werden?
• Kognitive Barrierefreiheit: Ist die Sprache verständlich? Sind Fehler klar erklärt?

Google selbst weist darauf hin, dass der Lighthouse Score kein Barrierefreiheits-Zertifikat ist. Er ist ein Startpunkt, kein Endpunkt.

Lighthouse ausführen: Chrome DevTools, CLI, CI/CD

Lighthouse kann auf drei Arten ausgeführt werden:

Chrome DevTools: F12 > Lighthouse Tab > "Accessibility" ankreuzen > "Analyze page load". Das Ergebnis erscheint als Bericht mit Score, Befunden und Verbesserungsvorschlägen direkt im Browser.

CLI: Per npm installieren: npm install -g lighthouse. Dann: lighthouse https://example.com --only-categories=accessibility --output=json. Die CLI-Version ist ideal für Automatisierung und Scripting.

CI/CD-Integration: In GitHub Actions, GitLab CI oder Jenkins lässt sich Lighthouse als Build-Step einbinden. Mit lighthouse-ci (LHCI) können Schwellenwerte definiert werden – z.B. "der Build scheitert bei einem Accessibility Score unter 90". Das verhindert Regressionen, ersetzt aber keinen vollständigen Audit.

PageSpeed Insights: Googles PageSpeed Insights unter pagespeed.web.dev nutzt Lighthouse im Backend und zeigt den Accessibility Score als Teil der Gesamtbewertung.

Score-Optimierung vs. echte Barrierefreiheit

Es gibt einen wichtigen Unterschied zwischen "den Score maximieren" und "die Seite barrierefrei machen". Typische Maßnahmen, die den Score verbessern, ohne echte Barrierefreiheit zu schaffen:

• Alt-Texte einfügen, die technisch vorhanden, aber inhaltlich wertlos sind ("Bild 1", "Foto")
• aria-label auf alles kleben, statt semantisches HTML zu verwenden
• Farbkontraste knapp über dem Schwellenwert einstellen, die für Menschen mit Seheinschränkungen trotzdem schwer lesbar sind

Echte Barrierefreiheit erfordert: Gute Alt-Texte, die den Bildinhalt tatsächlich beschreiben. Semantisches HTML statt ARIA-Workarounds. Kontraste, die komfortabel lesbar sind, nicht nur minimal konform. Und vor allem: manuelle Tests mit Tastatur und Screenreader. Der Lighthouse Score ist ein nützlicher Warnmelder, aber kein Qualitätssiegel.

Lighthouse im Vergleich zu spezialisierten A11y-Tools

Im Vergleich zu axe DevTools, WAVE oder Pa11y hat Lighthouse weniger Regeln und weniger Detailtiefe bei der Accessibility-Auswertung. Dafür bietet Lighthouse den Vorteil, dass es Performance, SEO, Best Practices und Barrierefreiheit in einem einzigen Lauf prüft.

Empfohlene Strategie: Lighthouse als schnellen Basis-Check nutzen und den Score als Monitoring-Metrik in der CI/CD-Pipeline tracken. Für detaillierte Barrierefreiheits-Analyse axe DevTools oder WAVE einsetzen. Für CI/CD-Integration mit maximaler Regelabdeckung pa11y oder @axe-core/playwright nutzen. Für den vollständigen Audit: manuelle Tests mit NVDA/VoiceOver und idealerweise Tests mit echten Nutzern assistiver Technologien.

Lighthouse ist ein hervorragender Einstieg – solange man versteht, dass ein grüner Score eine notwendige, aber keine hinreichende Bedingung für Barrierefreiheit ist.