Ratgeber

Lighthouse-Barrierefreiheit: den Shop selbst prüfen und den Wert richtig lesen

Veröffentlicht am 27. Oktober 2026

Die Lighthouse-Barrierefreiheit prüfen Sie kostenlos in Chrome: Entwicklertools öffnen, den Reiter Lighthouse wählen, nur die Kategorie Barrierefreiheit anhaken und den Bericht für Startseite, Produktseite und Warenkorb je einmal für Mobil und Desktop erstellen. Der Wert von 0 bis 100 ist ein gewichteter Durchschnitt automatischer Prüfungen; auch 100 heißt nur, dass diese Prüfungen nichts gefunden haben, nicht, dass Ihr Shop barrierefrei ist.

Dieser Artikel zeigt beide Wege (Chrome-Entwicklertools und PageSpeed Insights) Schritt für Schritt, rechnet die Punktzahl an einem Beispiel nach, übersetzt die für Shops wichtigsten Meldungen in WCAG-Kriterien und konkrete Arbeit im Shop und gibt Ihnen ein Protokoll zum Ausfüllen. Wo Lighthouse im Gesamtablauf einer Prüfung steht, zeigt die Übersicht Website auf Barrierefreiheit prüfen: Checkliste für Onlineshops.

Was Lighthouse ist und was es prüft

Lighthouse ist laut Google ein quelloffenes, automatisches Werkzeug mit Prüfungen zu Leistung, Barrierefreiheit, SEO und mehr. Es läuft in den Chrome-Entwicklertools, auf der Kommandozeile und hinter PageSpeed Insights. Die Barrierefreiheitsprüfungen stammen aus der Prüfbibliothek axe-core: Die Chrome-Doku zu den Bedienungshilfen in DevTools nennt axe als „the underlying engine that powers the Lighthouse panel“.

Lighthouse sagt das selbst über seine Grenzen. Über der Kategorie steht im deutschen Bericht laut Übersetzungsdatei von Lighthouse: „Durch die automatische Erkennung werden nicht alle Probleme erkannt. Auch die Barrierefreiheit deiner Web-App kann damit nicht garantiert werden, weshalb manuelle Tests empfohlen werden.“

Welche WCAG-Kriterien axe-core überhaupt automatisch prüfen kann und welche nicht, haben wir im Ratgeber WCAG-Check online Kriterium für Kriterium ausgezählt. Hier geht es um die Bedienung von Lighthouse und um das Lesen seines Werts.

Welche Seiten Sie prüfen

Lighthouse prüft immer genau eine Seite in einem Zustand. Für einen Shop empfehlen wir mindestens diese Stichprobe, jeweils für Mobil und Desktop:

Die Auswahl ist unsere Empfehlung. Zum Vergleich: Shopify verlangt für die Aufnahme in seinen Theme Store laut Theme-Store-Anforderungen einen durchschnittlichen Lighthouse-Barrierefreiheitswert von mindestens 90 „across the theme's product, collection, and home page, for both desktop and mobile“. Auch dort zählen also Mobil und Desktop getrennt.

Weg 1: Lighthouse in den Chrome-Entwicklertools

Dieser Weg ist der bessere für einen Shop, weil Sie Seiten in genau dem Zustand prüfen können, den Sie selbst sehen, also auch den gefüllten Warenkorb. Google empfiehlt die Entwicklertools ausdrücklich gegenüber der Lighthouse-Erweiterung, weil nur sie auch Seiten prüfen, die eine Anmeldung brauchen (Lighthouse-Überblick).

Die Beschriftungen. Google beschreibt die Oberfläche auf Englisch. Ist die Oberfläche der Entwicklertools auf Deutsch, lauten die Begriffe laut der deutschen Übersetzungsdatei der Chrome-Entwicklertools so:

Achtung: Das Kästchen für die Kategorie heißt in den deutschen Entwicklertools „Bedienungshilfen“, im fertigen Bericht heißt dieselbe Kategorie „Barrierefreiheit“ (Übersetzungsdatei von Lighthouse).

Startseite und Produktseite prüfen

1. Neues Inkognito-Fenster öffnen. Lighthouse wird laut Chrome-Doku zum Lighthouse-Bereich von Ihrer Umgebung beeinflusst, auch von Chrome-Erweiterungen und gespeicherten Einstellungen; empfohlen wird oft der Inkognito-Modus. Für Start- und Produktseite ist das der saubere Weg.
2. Seite aufrufen und Entwicklertools öffnen. Laut Chrome-Doku mit F12 oder Strg+Umschalt+I unter Windows und Linux, mit Cmd+Option+I auf dem Mac, oder über das Menü mit den drei Punkten rechts neben der Adresszeile und More Tools > Developer Tools (in englischem Chrome).
3. Reiter Lighthouse wählen. Er hieß bis zur Umbenennung in Chrome 83 noch Audits (Chrome-Doku).
4. Modus Navigation lassen. Er lädt die Seite neu und prüft sie direkt nach dem Laden (Lighthouse-Doku zu User Flows).
5. Gerät wählen. Zuerst Mobil. Laut Chrome-Doku ändert diese Einstellung die Kennung des Browsers und die Größe des Anzeigebereichs; wenn die mobile Fassung anders aussieht, kann das die Ergebnisse deutlich verändern.
6. Nur Barrierefreiheit anhaken. Unter Kategorien bleibt nur Accessibility beziehungsweise Bedienungshilfen aktiv. Die anderen Kategorien abzuwählen macht den Durchlauf schneller (Chrome-Doku zum Lighthouse-Bereich).
7. Analyse starten mit Analyze page load beziehungsweise Seitenaufbau analysieren. Nach einigen Sekunden erscheint der Bericht.
8. Wiederholen mit Desktop. Dieselbe Seite noch einmal mit Gerät Desktop prüfen und beide Berichte speichern (siehe unten).

Den Warenkorb prüfen

Beim Warenkorb gibt es zwei Fallen. Erstens ist der Warenkorb im frischen Inkognito-Fenster leer. Zweitens bietet Lighthouse in den Einstellungen die Option Clear storage beziehungsweise Speicherinhalt löschen, die laut Chrome-Doku den Speicher der Website vor der Prüfung leert. Nach unserer Lesart kann das den Warenkorb leeren, wenn Ihr Shop ihn im Browser speichert. So gehen Sie vor:

1. Legen Sie im selben Fenster einen typischen Artikel mit Variante in den Warenkorb und öffnen Sie die Warenkorbseite.
2. Wählen Sie im Lighthouse-Reiter den Modus Snapshot. Er prüft die Seite laut Chrome-Doku „in the exact state the page is in without reloading it“. Laut Lighthouse-Doku zu User Flows eignet er sich, um Barrieren tief in komplexen Formularen zu finden und Menüs und Bedienelemente zu bewerten, die erst nach einer Interaktion erscheinen.
3. Kategorie Barrierefreiheit, Gerät wie gewünscht, dann Analyze page state beziehungsweise Zustand der Seite analysieren.

Mit dem Snapshot prüfen Sie auf dieselbe Weise auch Zustände, die nach dem Laden nicht sichtbar sind: das aufgeklappte Mobilmenü, den geöffneten Mini-Warenkorb oder ein Größenberater-Fenster. Erst öffnen, dann Snapshot. Den Modus Timespan beziehungsweise Zeitspanne brauchen Sie dafür nicht; er enthält laut Lighthouse-Doku keine Kategorie Barrierefreiheit.

Weg 2: PageSpeed Insights

PageSpeed Insights ist der Weg ohne Entwicklertools, etwa am Rechner, auf dem Sie Chrome nicht verwenden. Laut Lighthouse-Überblick gehen Sie so vor:

1. pagespeed.web.dev öffnen.
2. Die Adresse der Seite eingeben.
3. Auf die Schaltfläche zum Analysieren klicken (in Googles Anleitung „Analyze“).

PageSpeed Insights lässt Lighthouse laut Google in einer simulierten Umgebung für Leistung, Barrierefreiheit, Best Practices und SEO laufen und berichtet für Mobilgeräte und Desktop. Sie bekommen also alle vier Kategorien und lesen nur den Teil Barrierefreiheit; die Kategorien vorher abwählen können Sie dort laut Chrome-Doku nicht.

Für den Warenkorb taugt PageSpeed Insights nicht. Die Prüfung läuft laut Google in einem Google-Rechenzentrum. Nach unserer Lesart ruft sie Ihre Seite deshalb wie ein neuer Besucher auf, ohne Ihren Warenkorb. Prüfen Sie den Warenkorb in den Entwicklertools.

Ergebnisse vergleichen. Die Chrome-Doku weist darauf hin, dass Berichte aus den Entwicklertools auf verschiedenen Rechnern nicht direkt vergleichbar sind, während PageSpeed Insights auf getrennten Servern einheitlichere Läufe liefert (Chrome-Doku). Für den Vorher-nachher-Vergleich derselben Seite nehmen Sie deshalb immer denselben Weg.

Wie der Wert berechnet wird

Die Chrome-Doku zur Bewertung (gelesen am 27.10.2026, zuletzt aktualisiert am 22.10.2025) sagt:

• Gewichteter Durchschnitt. Der Wert ist ein gewichteter Durchschnitt aller Barrierefreiheitsprüfungen. Die Gewichte beruhen auf der Einschätzung von axe, wie stark ein Fehler Nutzer trifft.
• Bestanden oder nicht bestanden. Jede Prüfung ist entweder bestanden oder nicht, Teilpunkte gibt es nicht. Die Doku nennt selbst das Beispiel: Haben einige Schaltflächen einen zugänglichen Namen und andere nicht, bekommt die Seite für diese Prüfung 0.
• Gewichte 10, 7 und 3. So stehen sie in der Tabelle der Doku. Die Doku hinkt dem Programm aber hinterher: In der Konfiguration von Lighthouse 13.5 zählen zusätzlich einige Prüfungen mit Gewicht 1 und die Prüfung der Zielgröße mit Gewicht 7, die Prüfung „Elemente mit sichtbarem Textlabel“ dagegen gar nicht mehr.
• Manuelle Prüfungen zählen nicht. Manuelle Prüfungen und Prüfungen mit geringer Auswirkung oder reinen Empfehlungen stehen nicht in der Tabelle, weil sie den Wert nicht beeinflussen.

Dazu kommt eine Regel aus dem Quellcode von Lighthouse: Prüfungen, die auf der Seite nichts zu prüfen fanden, bekommen das Gewicht 0 und erscheinen im Bericht als „Nicht zutreffend“. Hat Ihre Seite keine Tabelle und kein Video, zählen die Tabellen- und Videoprüfungen also gar nicht mit.

Die Gewichte ändern sich mit neuen Versionen. Mit Lighthouse 11 wurden laut Google alle Gewichte neu an die axe-Einstufungen angepasst und 13 neue Prüfungen ergänzt. Vergleichen Sie Werte deshalb nur mit Berichten derselben Zeit.

Rechenbeispiel

Beispiel, vereinfacht: Auf einer Produktseite sind zehn Prüfungen anwendbar, mit diesen Gewichten aus der Chrome-Doku:

Summe der Gewichte: 78. Bestanden: 68. Wert: 68 geteilt durch 78 ergibt gerundet 0,87, also 87. Ein einziges Bild ohne Alternativtext kostet hier 13 Punkte, genauso viel wie hundert Bilder ohne Alternativtext. Fällt stattdessen nur die Überschriftenreihenfolge durch, ergibt sich 75 geteilt durch 78, gerundet 96.

Was Sie daraus lernen:

• Der Wert zählt Prüfungen, nicht Fehler. Ein Shop mit 30 fehlenden Alternativtexten und einer mit einem fehlenden kann denselben Wert haben. Lesen Sie immer die Liste darunter.
• Ein Wert ist nur für diese eine Seite gültig. Ihre Produktseite kann 100 haben und der Warenkorb 80.
• Ein höherer Wert kann weniger geprüft haben. Weil nicht zutreffende Prüfungen wegfallen, hat eine einfache Seite mit wenig Inhalt weniger Gelegenheiten durchzufallen.

PageSpeed Insights ordnet die Werte farbig ein: laut Google gilt 90 oder mehr als gut, 50 bis 89 als verbesserungswürdig, unter 50 als schlecht. Das ist eine Einstufung des Werts, keine Aussage über die Barrierefreiheit Ihres Shops.

Warum 100 nicht barrierefrei heißt

Google schreibt in der Ankündigung von Lighthouse 11, dass alle automatischen Prüfungen zu bestehen und 100 zu erreichen „does not guarantee that the audited page is accessible; manual testing is still important“. Seitdem klappt Lighthouse den Abschnitt mit den manuellen Prüfungen automatisch auf, sobald alle automatischen Prüfungen bestanden sind.

Drei Gründe, warum der Wert täuschen kann:

1. Lighthouse prüft, ob etwas da ist, nicht ob es taugt. Ein Alternativtext „Bild“ besteht die Prüfung.
2. Bedienung prüft Lighthouse nicht. Die Chrome-Doku teilt die Frage nach Barrierefreiheit in zwei: Kann ich die Seite mit Tastatur oder Screenreader bedienen? Ist sie für Screenreader richtig ausgezeichnet? Bei der ersten, so die Doku, können die Entwicklertools nicht helfen; das finden Sie nur heraus, indem Sie die Seite selbst mit Tastatur oder Screenreader benutzen.
3. Lighthouse prüft nur den Zustand, den es sieht. Im Modus Navigation ist das die frisch geladene Seite. Geöffnete Menüs, Fehlermeldungen im Checkout oder der Ablauf bis zur Zahlung kommen darin nicht vor.

Wichtige Meldungen für Shops: Bedeutung, Kriterium, Behebung

Die Spalte „Meldung“ zeigt den Titel einer nicht bestandenen Prüfung im deutschen Bericht aus der Übersetzungsdatei von Lighthouse, dahinter den englischen Titel. Die Gewichte stammen aus der Chrome-Doku zur Bewertung, das Gewicht der Zielgröße, die dort noch fehlt, aus der Konfiguration von Lighthouse 13.5; die Zuordnung zu WCAG-Kriterien aus der Regelliste von axe-core, die Kriterien aus den WCAG 2.2. Die Spalten „Was es im Shop meist ist“ und „So beheben Sie es im Shop“ sind unsere Einschätzung für typische Shops.

Zu jeder Meldung zeigt der Bericht die betroffenen Elemente. Klappen Sie die Meldung auf; laut Chrome-Doku führt der Link „Learn more“ zur Erklärung der Prüfung. Kopieren Sie die betroffenen Elemente in Ihr Protokoll, bevor Sie etwas ändern.

Die Meldung zu Links und Farbe ist schief übersetzt. Der deutsche Titel der nicht bestandenen Prüfung lautet laut Übersetzungsdatei „Links sind durch Farbe erkennbar.“, gemeint ist im Englischen „Links rely on color to be distinguishable“: Die Links sind nur durch Farbe erkennbar, und genau das ist der Fehler.

Die manuellen Prüfungen ernst nehmen

Unter den automatischen Ergebnissen steht im Bericht ein eingeklappter Abschnitt „Zusätzliche Elemente zur manuellen Überprüfung“, englisch „Additional items to manually check“ (Übersetzungsdatei). Lighthouse erklärt dazu: „Diese Prüfungen sind für Bereiche vorgesehen, für die automatische Testtools nicht geeignet sind.“ Sie zählen nicht zum Wert, betreffen aber die Bedienung, an der Kunden im Shop am ehesten scheitern.

Die zehn Einträge stehen auch im deutschen Bericht auf Englisch; im Quellcode von Lighthouse sind sie nicht zur Übersetzung vorgesehen. Die Tabelle übersetzt sie und macht daraus einen Prüfschritt im Shop. Die Zuordnung zu WCAG-Kriterien ist unsere Einschätzung, Lighthouse selbst nennt keine.

Die Beschreibungen in der zweiten Spalte sind aus den Texten der Einträge im Quellcode von Lighthouse übersetzt. Die meisten Zeilen erledigen Sie in einem Durchgang mit der Tastatur; den Ablauf in zehn Minuten zeigt der Tastaturtest für Onlineshops. Google verweist für die manuelle Prüfung auf den Leitfaden How to review for accessibility, der ebenfalls mit der Tastatur beginnt.

Einen zweiten automatischen Blick mit anderer Darstellung bietet WAVE, das Fundstellen direkt auf der Seite markiert: WAVE: den eigenen Shop Schritt für Schritt prüfen.

Ergebnis dokumentieren

Bericht speichern. Nach dem Lauf bietet das Menü mit den drei Punkten im Bericht laut Chrome-Doku Drucken, Kopieren, Speichern und das Öffnen in einem eigenen Viewer. Laut Lighthouse-Überblick können Sie den Bericht über Save as JSON speichern und später im Lighthouse Viewer wieder öffnen. Speichern Sie je Seite und Gerät einen Bericht, zum Beispiel als „2026-10-27_produktseite_mobil.json“.

Protokoll führen. Kopieren Sie diese Tabelle in ein Dokument oder eine Tabellenkalkulation:

Kopfdaten: Datum: ______ · Geprüft von: ______ · Weg (Entwicklertools oder PageSpeed Insights): ______ · Chrome-Version: ______ · Theme und Version: ______ · Anlass (Erstprüfung, Update, neue App): ______

Den Wert nicht als Nachweis verkaufen. Schreiben Sie in Ihre Unterlagen „Lighthouse-Wert 100 auf drei Seiten, automatische Prüfung“ und nicht „barrierefrei geprüft“. Die automatische Prüfung ist ein Baustein; zusammen mit dem Tastaturtest und den manuellen Einträgen wird daraus eine nachvollziehbare Selbstprüfung.

Wiederholen. Unsere Empfehlung: nach jedem Theme-Update, nach jeder neuen App oder jedem neuen Plugin, das im Shop etwas anzeigt, und nach Änderungen an Farben oder eigenem Code. Prüfen Sie dann mit demselben Weg wie beim letzten Mal, damit die Werte vergleichbar bleiben.

Checkliste für Ihren Lighthouse-Durchgang

• Startseite, Produktseite mit Varianten und Warenkorb mit Artikel ausgewählt
• Start- und Produktseite im Inkognito-Fenster, Modus Navigation
• Warenkorb im Modus Snapshot, nach dem Befüllen, ohne Speicherinhalt zu löschen
• Nur Kategorie Barrierefreiheit (in deutschen Entwicklertools „Bedienungshilfen“)
• Jede Seite für Mobil und Desktop
• Jede nicht bestandene Prüfung aufgeklappt, betroffene Elemente notiert
• Abschnitt „Zusätzliche Elemente zur manuellen Überprüfung“ Punkt für Punkt durchgegangen
• Geöffnete Menüs, Mini-Warenkorb und Popups zusätzlich per Snapshot geprüft
• Berichte als JSON gespeichert, Protokoll ausgefüllt
• Wert nicht als Beleg für Barrierefreiheit ausgegeben

Ihr nächster Schritt

Machen Sie zusätzlich den kostenlosen Scan. Er prüft Startseite, Produktseite und Warenkorb und zeigt, was zuerst behoben werden sollte. Wie Lighthouse findet er als automatische Prüfung nur einen Teil der Barrieren; die manuellen Einträge und der Tastaturtest bleiben Ihre Aufgabe.

Stand: 27.10.2026. Quellen gelesen am 27.10.2026.