Was ist das Google Lighthouse Accessibility Audit?
Das Google Lighthouse Accessibility Audit ist ein automatisierter Barrierefreiheitstest, der in Googles Open-Source-Tool Lighthouse integriert ist. Es prüft Webseiten gegen eine definierte Menge an Accessibility-Regeln und liefert einen Score zwischen 0 und 100. Lighthouse nutzt dafür die axe-core-Engine von Deque Systems, die WCAG 2.1 Level A und AA als Prüfgrundlage verwendet.
Lighthouse ist direkt in die Chrome DevTools integriert und erfordert keine Installation. Entwickler öffnen die DevTools, wählen den Lighthouse-Tab und starten den Audit mit einem Klick. Das Tool simuliert dabei den Seitenaufruf, analysiert den gerenderten DOM und prüft HTML-Elemente auf korrekte semantische Auszeichnung, ARIA-Attribute, Farbkontraste und weitere Barrierefreiheitskriterien. Das Ergebnis ist ein detaillierter Bericht mit dem Gesamtscore, bestandenen und nicht bestandenen Prüfungen sowie konkreten Hinweisen zur Behebung.
Neben der Barrierefreiheit prüft Lighthouse auch Performance, SEO, Best Practices und Progressive Web App-Kriterien. Das macht es zu einem vielseitigen Werkzeug für die Qualitätssicherung von Webseiten. Für Teams, die das Thema barrierefreie Überschriftenstrukturen bereits umsetzen, ist der Lighthouse Accessibility Audit der logische nächste Schritt zur systematischen Qualitätskontrolle.
So funktioniert der Lighthouse Accessibility Score
Der Lighthouse Accessibility Score ist ein gewichteter Durchschnitt aller einzelnen Accessibility-Audits. Jedes Audit folgt einem strikten Pass-or-Fail-Prinzip: Entweder eine Seite besteht eine Prüfung vollständig oder sie erhält null Punkte. Teilpunkte gibt es nicht. Wenn etwa drei von fünf Buttons einen barrierefreien Namen haben, gilt der Audit als nicht bestanden und wird mit null bewertet.
Die Gewichtung der einzelnen Audits basiert auf den axe user impact assessments von Deque Systems. Prüfungen mit hohem Einfluss auf die Nutzererfahrung – etwa fehlende Alternativtexte oder versteckte Inhalte durch falsches aria-hidden – erhalten ein höheres Gewicht als weniger kritische Prüfungen. Ein Audit mit Gewicht 10 beeinflusst den Gesamtscore fünfmal stärker als ein Audit mit Gewicht 2.
Wichtig für die Einordnung: Der Score bezieht nur automatisiert prüfbare Kriterien ein. Manuelle Audits und Best-Practice-Empfehlungen, die Lighthouse ebenfalls anzeigt, fließen nicht in die Berechnung ein. Der Score spiegelt also nur einen Teil der tatsächlichen Barrierefreiheit wider. Lighthouse selbst weist darauf hin, dass automatisierte Tests lediglich eine Teilmenge aller möglichen Probleme erkennen können.
Lighthouse Accessibility Audit durchführen – Schritt für Schritt
Der schnellste Weg zum Accessibility Audit führt über die Chrome DevTools. Öffnen Sie die zu prüfende Seite in Google Chrome, klicken Sie mit der rechten Maustaste und wählen Sie Untersuchen. In den DevTools finden Sie den Lighthouse-Tab, wo Sie die Kategorie Accessibility auswählen und zwischen Desktop- und Mobile-Simulation wählen können. Nach dem Klick auf Seitenladevorgang analysieren generiert Lighthouse den Bericht innerhalb weniger Sekunden.
Für die Integration in automatisierte Workflows bietet Lighthouse eine CLI-Variante. Nach der Installation über npm lässt sich der Audit direkt aus dem Terminal starten. Der folgende Befehl führt ausschließlich den Accessibility-Audit durch und speichert den Bericht als HTML-Datei:
npm install -g lighthouse
lighthouse https://example.com --only-categories=accessibility --output html --output-path ./accessibility-report.html
Alternativ steht Lighthouse über Googles PageSpeed Insights als Online-Tool zur Verfügung. Der Vorteil: Kein lokales Setup nötig. Der Nachteil: Seiten hinter einer Authentifizierung oder lokale Entwicklungsumgebungen können nicht getestet werden. Für umfassende Tests während der Entwicklung bleibt die DevTools-Variante die flexibelste Option.
Wer neben Lighthouse weitere browserbasierte Prüfwerkzeuge kennenlernen möchte, findet bei den Firefox Accessibility-Testing-Tools ergänzende Ansätze für die Barrierefreiheitsprüfung.
Die wichtigsten Audit-Kategorien im Überblick
Lighthouse gruppiert die Accessibility-Audits in thematische Kategorien. Im Bereich Navigation und Orientierung prüft das Tool, ob die Seite eine korrekte Heading-Hierarchie aufweist, Skip-Links für Tastaturnutzer vorhanden sind und die Tab-Reihenfolge logisch ist. Diese Kategorie hat besonders hohes Gewicht, weil Navigationsprobleme alle Nutzer mit motorischen Einschränkungen und Screenreader-Anwender direkt betreffen.
Die Kategorie ARIA-Attribute kontrolliert, ob ARIA-Rollen korrekt eingesetzt werden, ob aria-label und aria-labelledby vorhandene Elemente referenzieren und ob interaktive Elemente programmatisch erkennbare Namen besitzen. Fehlerhaft eingesetzte ARIA-Attribute sind besonders tückisch: Sie können Barrierefreiheitsprobleme nicht nur nicht lösen, sondern aktiv verschlimmern, indem sie Screenreadern falsche Informationen liefern.
Im Bereich Kontrast und Wahrnehmbarkeit prüft Lighthouse, ob Vordergrund- und Hintergrundfarben ausreichend Kontrast bieten. Das WCAG-Erfolgskriterium 1.4.3 fordert ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text. Darüber hinaus kontrolliert Lighthouse, ob Bilder Alternativtexte besitzen, Formulareingaben mit Labels verknüpft sind und die Seitensprache im HTML-Dokument deklariert ist.
Lighthouse Accessibility Score: Bewertungsskala
| 0 – 49 | Schlecht (rot) | Erhebliche Barrieren vorhanden. Sofortige Maßnahmen erforderlich, insbesondere für BFSG-Konformität. |
| 50 – 89 | Verbesserungswürdig (orange) | Mehrere Probleme erkannt. Systematische Behebung nach Gewichtung und Impact priorisieren. |
| 90 – 100 | Gut (grün) | Automatisierte Prüfungen bestanden. Manuelle Tests und Screenreader-Prüfung sind trotzdem notwendig. |
Grenzen von Lighthouse – Was der Score nicht zeigt
Lighthouse kann nach Expertenschätzungen nur etwa 30 bis 40 Prozent aller Barrierefreiheitsprobleme automatisiert erkennen. Die restlichen 60 bis 70 Prozent erfordern manuelle Prüfung durch geschulte Tester. Ein Score von 100 bedeutet daher ausdrücklich nicht, dass eine Website barrierefrei ist. Es bedeutet lediglich, dass alle automatisiert prüfbaren Kriterien bestanden wurden.
Die größten blinden Flecken liegen bei der Tastaturbedienbarkeit. Lighthouse kann nicht prüfen, ob alle interaktiven Elemente per Tastatur erreichbar sind, ob Keyboard-Traps existieren oder ob die Tab-Reihenfolge logisch ist. Ebenso wenig simuliert das Tool die tatsächliche Screenreader-Erfahrung: Es prüft zwar, ob ARIA-Attribute formal korrekt sind, kann aber nicht beurteilen, ob die Vorlese-Reihenfolge sinnvoll ist oder ob Linktexte wie Hier klicken im Kontext verständlich sind.
Dynamische Inhalte wie Modals, Live-Updates oder Fehlermeldungen, die zur Laufzeit eingeblendet werden, erfasst Lighthouse häufig nicht. Diese Elemente müssen mit aria-live-Regionen oder korrektem Fokusmanagement für Screenreader zugänglich gemacht werden – ein Bereich, der ausschließlich durch manuelle Tests abgedeckt werden kann. Auch die Qualität von Alternativtexten bei Bildern entzieht sich der automatisierten Prüfung: Lighthouse erkennt, ob ein alt-Attribut vorhanden ist, kann aber nicht beurteilen, ob der Text das Bild tatsächlich sinnvoll beschreibt.
Lighthouse in CI/CD-Pipelines integrieren
Die eigentliche Stärke von Lighthouse entfaltet sich in der Automatisierung. Mit Lighthouse CI lassen sich Accessibility-Audits in bestehende Build-Pipelines integrieren, sodass jede Codeänderung automatisch auf Barrierefreiheitsregressionen geprüft wird. Teams definieren Schwellenwerte für den Accessibility Score – fällt ein Deployment darunter, schlägt der Build fehl.
Für die programmatische Integration steht die Node.js-API zur Verfügung. Der folgende Code zeigt, wie ein Accessibility-Audit in einem automatisierten Testlauf ausgeführt und der Score ausgelesen wird:
const lighthouse = require('lighthouse');
const chromeLauncher = require('chrome-launcher');
async function runAccessibilityAudit(url) {
const chrome = await chromeLauncher.launch({chromeFlags: ['--headless']});
const options = {
port: chrome.port,
onlyCategories: ['accessibility']
};
const result = await lighthouse(url, options);
const score = result.lhr.categories.accessibility.score * 100;
console.log(`Accessibility Score: ${score}`);
if (score < 90) {
console.error('Accessibility-Schwellenwert nicht erreicht!');
process.exit(1);
}
await chrome.kill();
}
runAccessibilityAudit('https://example.com');
Alternativ bietet axe-core von Deque eine eigenständige API, die sich noch feingranularer konfigurieren lässt. Damit können einzelne WCAG-Regeln gezielt aktiviert oder deaktiviert und spezifische Seitenbereiche getestet werden. Für Symfony-Projekte mit Sulu CMS lässt sich axe-core über Playwright oder Cypress in bestehende Frontend-Test-Suiten einbinden. Never Code Alone unterstützt Teams bei der Einrichtung solcher automatisierten Accessibility-Pipelines – von der Konfiguration bis zur Integration in bestehende DevOps-Workflows.
Lighthouse und das Barrierefreiheitsstärkungsgesetz (BFSG)
Seit Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) Unternehmen, deren digitale Dienstleistungen für Verbraucher bestimmt sind, zur Einhaltung der EN 301 549. Dieser europäische Standard verweist auf die WCAG 2.1 Level AA als technische Grundlage. Lighthouse prüft einen relevanten Teil dieser Anforderungen automatisiert – ist aber allein nicht ausreichend für den Nachweis der BFSG-Konformität.
Der Grund: Die WCAG umfassen insgesamt 50 Erfolgskriterien auf Level AA, von denen Lighthouse nur die maschinell prüfbaren abdeckt. Kriterien, die menschliches Urteilsvermögen erfordern – etwa die Verständlichkeit von Texten (3.1.5), die Konsistenz der Navigation (3.2.3) oder die Qualität von Alternativtexten (1.1.1) – können nur durch manuelle Audits verifiziert werden. Für eine vollständige BFSG-Konformitätsprüfung ist Lighthouse daher ein wichtiger Baustein, aber kein Ersatz für eine professionelle Bewertung.
In der Praxis hat sich ein gestufter Ansatz bewährt: Lighthouse und axe-core decken die automatisiert prüfbaren Kriterien ab, ergänzt durch manuelle Tests mit Screenreadern wie NVDA oder VoiceOver, Tastatur-Navigation-Tests und Usability-Prüfungen mit Betroffenen. Never Code Alone bietet genau diesen kombinierten Ansatz als Accessibility-Audit an, der beide Ebenen systematisch abdeckt.
Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign
Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.
Fazit: Lighthouse als Startpunkt für systematische Barrierefreiheit
Google Lighthouse ist das zugänglichste Werkzeug für den Einstieg in die Barrierefreiheitsprüfung: kostenlos, direkt im Browser verfügbar und ohne Vorkenntnisse nutzbar. Der Accessibility Score liefert eine schnelle Orientierung, wie gut eine Webseite die automatisiert prüfbaren WCAG-Kriterien erfüllt. Für Entwicklungsteams, die Lighthouse in ihre CI/CD-Pipeline integrieren, wird der Score zur messbaren Qualitätsmetrik, die Regressionen frühzeitig erkennt.
Gleichzeitig ist es entscheidend, den Score nicht mit vollständiger Barrierefreiheit gleichzusetzen. Die 30 bis 40 Prozent der Probleme, die Lighthouse erkennt, sind der automatisierbare Anteil. Tastaturbedienbarkeit, Screenreader-Erfahrung, Inhaltsverständlichkeit und dynamische Interaktionen erfordern manuelle Tests und Expertise. Wer das BFSG ernst nimmt, kombiniert automatisierte Tools mit professionellen Audits.
Sie möchten Ihre Website systematisch auf Barrierefreiheit prüfen – von Lighthouse-Integration in Ihre Pipeline bis zum vollständigen BFSG-Konformitätsaudit? Never Code Alone unterstützt Sie mit automatisierten Tests, manuellen Prüfungen und Schulungen für Ihr Entwicklungsteam. Vereinbaren Sie eine kostenlose Erstberatung unter roland@nevercodealone.de oder telefonisch unter +49 176 24747727.
Häufig gestellte Fragen (FAQ)
Die folgenden Fragen beantworten die wichtigsten Aspekte rund um das Google Lighthouse Accessibility Audit – von der Score-Berechnung über die Grenzen automatisierter Tests bis zur Integration in professionelle Entwicklungs-Workflows.
Was prüft das Google Lighthouse Accessibility Audit 2026?
Das Lighthouse Accessibility Audit prüft Webseiten automatisiert gegen WCAG 2.1 Level A und AA Kriterien. Es nutzt die axe-core-Engine und kontrolliert unter anderem Farbkontraste, ARIA-Attribute, Alternativtexte, Formular-Labels, Heading-Strukturen und Seitensprache. Der Audit liefert einen Score zwischen 0 und 100 sowie konkrete Hinweise zur Fehlerbehebung.
Wie wird der Lighthouse Accessibility Score 2026 berechnet?
Der Score ist ein gewichteter Durchschnitt aller einzelnen Accessibility-Audits. Jeder Audit wird nach dem Pass-or-Fail-Prinzip bewertet – Teilpunkte gibt es nicht. Die Gewichtung basiert auf den axe user impact assessments: Audits mit hohem Einfluss auf die Nutzererfahrung fließen stärker in den Gesamtscore ein als weniger kritische Prüfungen.
Reicht ein Lighthouse Score von 100 für BFSG-Konformität 2026?
Nein. Ein Score von 100 bedeutet, dass alle automatisiert prüfbaren Kriterien bestanden wurden. Lighthouse erkennt aber nur etwa 30 bis 40 Prozent aller Barrierefreiheitsprobleme. Für die BFSG-Konformität nach EN 301 549 sind zusätzlich manuelle Tests mit Screenreadern, Tastatur-Navigation-Prüfungen und Usability-Tests erforderlich.
Welche WCAG-Kriterien prüft Lighthouse 2026 nicht?
Lighthouse kann keine Kriterien prüfen, die menschliches Urteilsvermögen erfordern. Dazu gehören die Qualität von Alternativtexten, Verständlichkeit von Inhalten, konsistente Navigation, sinnvolle Linktexte, korrekte Tab-Reihenfolge und die Bedienbarkeit dynamischer Inhalte wie Modals oder Live-Updates. Diese Bereiche erfordern manuelle Audits.
Wie lässt sich Lighthouse 2026 in CI/CD-Pipelines integrieren?
Lighthouse CI ermöglicht die Integration in Build-Pipelines über npm. Teams definieren Schwellenwerte für den Accessibility Score – fällt ein Deployment darunter, schlägt der Build fehl. Alternativ bietet die Node.js-API programmatischen Zugriff auf einzelne Audit-Ergebnisse, die sich in bestehende Testframeworks wie Playwright oder Cypress einbinden lassen.
Was ist der Unterschied zwischen Lighthouse und axe DevTools?
Beide nutzen die axe-core-Engine, aber axe DevTools bietet eine umfangreichere Regelsammlung und detailliertere Ergebnisse. Lighthouse ist in Chrome integriert und sofort nutzbar, während axe DevTools als separate Erweiterung installiert wird. In Tests hat Lighthouse einige Probleme übersehen, die axe DevTools erkannt hat, da die Implementierung nicht vollständig identisch ist.
Welche Audit-Kategorien hat Lighthouse für Barrierefreiheit?
Lighthouse gruppiert Accessibility-Audits in Kategorien wie Navigation (Heading-Hierarchie, Skip-Links, Tab-Reihenfolge), ARIA (korrekte Rollen, Labels, Attribute), Kontrast (Farbverhältnisse zwischen Text und Hintergrund), Namen und Labels (Buttons, Formulare, Links) sowie Sprache und Tabellen. Jede Kategorie enthält einzelne Prüfungen mit definierter Gewichtung.
Warum zeigt Lighthouse bei jedem Durchlauf unterschiedliche Scores?
Lighthouse simuliert den Seitenaufruf und analysiert den gerenderten DOM. Schwankungen entstehen durch unterschiedliche Netzwerkbedingungen, asynchron geladene Inhalte oder zeitlich verzögertes Rendering von Elementen. Für verlässliche Ergebnisse empfiehlt sich die Ausführung über die CLI mit festgelegten Netzwerkbedingungen oder die Mittelwertbildung aus mehreren Durchläufen.
Kann Lighthouse die Tastaturbedienbarkeit einer Website prüfen?
Nein. Das ist einer der größten blinden Flecken des Tools. Lighthouse kann nicht testen, ob alle interaktiven Elemente per Tastatur erreichbar sind, ob Keyboard-Traps existieren oder ob der Fokus nach Interaktionen korrekt gesetzt wird. Tastaturbedienbarkeit ist ein zentrales WCAG-Kriterium und muss manuell geprüft werden.
Wie unterscheidet sich Lighthouse von WAVE und Accessibility Insights?
Lighthouse ist in Chrome integriert und liefert einen Gesamtscore mit gewichteten Audits. WAVE von WebAIM markiert Probleme visuell direkt im Seitenkontext und eignet sich für schnelle visuelle Prüfungen. Accessibility Insights von Microsoft kombiniert automatisierte Tests mit geführten manuellen Prüfungen für vollständige WCAG-Konformitätsbewertungen. Idealerweise ergänzen sich alle drei Tools.
Prüft Lighthouse auch die mobile Barrierefreiheit?
Lighthouse bietet eine Mobile-Simulation, die den Audit unter Bedingungen eines mobilen Geräts durchführt. Dabei werden Viewport-Größe und Netzwerk-Throttling angepasst. Touch-Zielgrößen und mobile-spezifische Interaktionsmuster werden teilweise geprüft, aber nicht vollständig. Für umfassende mobile Accessibility-Tests sind zusätzliche Tests auf echten Geräten mit TalkBack oder VoiceOver notwendig.
Wie kann Never Code Alone bei Lighthouse Accessibility Audits helfen?
Never Code Alone bietet den kombinierten Ansatz aus automatisierten Lighthouse-Tests und manuellen Accessibility-Audits. Das umfasst die Integration von Lighthouse CI in bestehende Pipelines, ergänzende Tests mit axe-core und Screenreadern sowie vollständige BFSG-Konformitätsprüfungen nach EN 301 549. Kontakt: roland@nevercodealone.de oder +49 176 24747727.