Lighthouse zeigt 100: Warum axe trotzdem Fehler finden kann

Lighthouse zeigt bei Barrierefreiheit 100 Punkte, aber axe meldet Fehler auf derselben Seite. Das kann an der Regelauswahl, unterschiedlichen Versionen oder einem anderen Seitenzustand liegen. Die Zahl allein beweist weder Barrierefreiheit noch WCAG-Konformität. W3C erklärt, warum dafür auch menschliche Prüfung nötig ist.

Für diesen Beitrag haben wir den Unterschied auf einer Demo-Seite nachgestellt. Lighthouse erreichte 100 Punkte, während ein direkter axe-Lauf mit derselben Engine-Version sechs Regeln als fehlgeschlagen meldete. Nach der Korrektur meldete axe diese Fehler nicht mehr.

Was misst der Lighthouse-Score für Barrierefreiheit?

Der Score fasst ausgewählte automatische Prüfungen als gewichteten Mittelwert zusammen. Jede bewertete Prüfung besteht oder fällt durch. Ein einzelner unbeschrifteter Button lässt deshalb die gesamte Prüfung button-name scheitern, auch wenn alle anderen Buttons beschriftet sind. Mehr betroffene Buttons erhöhen den Abzug für diese eine Prüfung nicht. Das beschreibt die offizielle Erklärung zur Berechnung.

Zu den bewerteten Prüfungen gehören etwa Button-Namen, Formularbeschriftungen, Textkontrast, gültige ARIA-Attribute und die Seitensprache. Ihre Gewichte unterscheiden sich: In Lighthouse 13.5.0 hat button-name das Gewicht 10, color-contrast das Gewicht 7. Ein höheres Gewicht bedeutet einen größeren Einfluss auf den Score.

Für die genaue Auswahl ist die Konfiguration der verwendeten Lighthouse-Version maßgeblich:

• Manuelle Prüfungen, etwa zur logischen Tab-Reihenfolge, haben Gewicht 0.
• Einige automatische Hinweise, etwa empty-heading, haben ebenfalls Gewicht 0. Sie können im Bericht stehen, ohne die Zahl zu senken.
• Nicht anwendbare Prüfungen zählen nicht in den Mittelwert. Eine Seite ohne entsprechende Elemente hat dadurch keine zusätzlichen bestandenen Tests.

Lighthouse rundet den Mittelwert. Lies deshalb auch bei 100 die einzelnen Ergebnisse. Der Score ist weder ein Anteil erfüllter WCAG-Kriterien noch eine Zählung aller Barrieren.

Warum unterscheiden sich die Regeln bei Lighthouse und axe?

Lighthouse nutzt axe-core mit einer eigenen Regelauswahl. In Version 13.5.0 beginnt diese mit den Tags wcag2a und wcag2aa. Tags sind Gruppenkennzeichnungen für Regeln. Anschließend schaltet Lighthouse einzelne Regeln gezielt ein oder aus. Das steht im Quellcode des Accessibility-Gatherers.

Lighthouse schaltet auch target-size aus dem WCAG-2.2-Regelsatz und autocomplete-valid aus dem WCAG-2.1-Regelsatz ein. Das sind Einzelaktivierungen; Lighthouse schaltet nicht den gesamten Tag wcag22aa ein. Die Basisauswahl beschränkt also nicht alle Prüfungen auf WCAG 2.0. Andere Regeln sind ausdrücklich deaktiviert.

Eine separate axe-Integration kann wiederum andere Tags, ausgeschlossene Bereiche oder deaktivierte Regeln verwenden. „Mit axe getestet“ beschreibt den Prüfumfang noch nicht. Die axe-API dokumentiert diese Einstellungen.

Unser Test: 100 Punkte und sechs fehlgeschlagene Regeln

Unsere eigens für diesen Beitrag erstellte Produktdemo zeigt dieselbe Leuchte in zwei Varianten: mit gezielt eingebauten Barrieren und mit den entsprechenden Korrekturen. Öffne dort den Fall „Regelauswahl“. Alle sechs Probleme in der folgenden Tabelle stammen aus dieser Demo. Auf der Seite kannst Du auch den verwendeten Quellcode ansehen.

Wir prüften die verlinkten Seiten auf Deutsch und Englisch. Lighthouse 13.5.0 und der direkte axe-Lauf verwendeten beide axe-core 4.13.0, denselben Chrome-Browser und dieselbe Desktop-Fenstergröße. Für axe aktivierten wir wcag2a, wcag2aa, wcag21a, wcag21aa und wcag22aa. Beide Scans erfassten das ganze Dokument einschließlich Anleitung und Steuerung, ohne Ausschlüsse.

Lighthouse erreichte 100 und meldete keine fehlgeschlagene Accessibility-Prüfung. axe meldete die folgenden sechs Regeln als fehlgeschlagen. Eine Regel kann mehrere Elemente betreffen; die Zahl sechs bezeichnet hier Regeln. Auf schmalen Bildschirmen kannst Du die Tabelle seitlich scrollen.

Nach der Korrektur fand der gleich konfigurierte axe-Lauf keine Verletzung mehr. Das bestätigt die gezeigten Korrekturen im getesteten Zustand.

Schlecht und besser: Eine Grafik verständlich benennen

Eine Person mit Screenreader braucht die Information der Grafik in Textform. Im schlechten Beispiel fehlt dieser Text:

<div role="img" id="lh-chart"></div>

Für eine einfache Grafik mit zwei Werten kann ein zugänglicher Name die Information vermitteln:

<div role="img" id="lh-chart"
     aria-label="Helligkeit: niedrige Stufe 300 Lumen, hohe Stufe 500 Lumen."></div>

Im korrigierten Testbeispiel bestand role-img-alt. Der Name beschreibt die dargestellten Werte. Bei komplexen Diagrammen brauchst Du gegebenenfalls eine ausführliche Beschreibung oder Datentabelle. Ist die Grafik rein dekorativ, muss sie nicht künstlich benannt werden. Dann ist eine Darstellung ohne Bildrolle oft geeigneter.

Schlecht und besser: Textabstände anpassbar lassen

Diese Inline-Regel kann verhindern, dass ein eigenes Stylesheet den Zeichenabstand für bessere Lesbarkeit verändert:

<p id="lh-spacing" style="letter-spacing: 0 !important">Warmes Licht zum Lesen, Schreiben und für die letzte Aufgabe des Tages.</p>

Im korrigierten Beispiel entfernen wir diese Festlegung:

<p id="lh-spacing">Warmes Licht zum Lesen, Schreiben und für die letzte Aufgabe des Tages.</p>

Damit bestand avoid-inline-spacing. Prüfe zusätzlich, ob vergrößerte Abstände Inhalte abschneiden oder Bedienelemente verdecken. WCAG 1.4.12 verlangt, dass passende Textabstandsänderungen ohne Verlust von Inhalt oder Funktion möglich sind. Dabei gelten nur die Abstandseigenschaften, die die jeweilige Sprache und Schrift verwendet. Die Regel verlangt nicht, alle Texte standardmäßig mit diesen Abständen zu gestalten.

Kann Lighthouse einen geöffneten Dialog prüfen?

Lighthouse kann den aktuellen Seitenzustand mit einem Snapshot prüfen. Ein normaler Navigation-Lauf untersucht den Zustand nach dem Laden. Ein Snapshot kann einen danach geöffneten Dialog erfassen. User Flows verbinden solche Schritte. Die Lighthouse-Dokumentation zu User Flows beschreibt die Modi.

Für diesen Vergleich hat die Produktdemo einen eigenen Fall: Dialogzustand. Der Schließen-Button ist zunächst nicht angezeigt. Der Navigation-Lauf erreichte 100. Nach dem Öffnen meldete der Snapshot button-name; der Score sank auf 94. In der verbesserten Dialogvariante hat der Button einen Namen, und auch der Snapshot erreichte 100. Die 94 gehört zu diesem Testaufbau: Gewichte und die übrigen anwendbaren Prüfungen beeinflussen die Zahl.

Dieser getestete Ablauf verwendet eine bereits geöffnete Puppeteer-Seite als page. Er öffnet die Dialogdemo über #lh-open und prüft den sichtbaren Dialog #lh-dialog:

import { startFlow } from 'lighthouse';

const url = 'https://demo.navable.io/de/examples/v1/lighthouse-axe/barriers/dialog';
await page.setViewport({ width: 1280, height: 900, deviceScaleFactor: 1 });
const flow = await startFlow(page, {
  config: {
    extends: 'lighthouse:default',
    settings: {
      onlyCategories: ['accessibility'],
      formFactor: 'desktop',
      screenEmulation: { disabled: true },
      throttlingMethod: 'provided',
      disableStorageReset: true,
    },
  },
});
await flow.navigate(url);
await page.click('#lh-open');
await page.waitForSelector('#lh-dialog');
await flow.snapshot({ name: 'Opened lamp settings' });
const report = await flow.createFlowResult();

axe meldete in beiden geöffneten Varianten aria-hidden-focus zur weiteren Prüfung (incomplete). Bei unseren Tastaturtests blieb der Fokus mit Tab und Umschalt+Tab im Dialog; Escape setzte ihn auf den öffnenden Button zurück. Diese Beobachtungen ersetzen keinen Screenreader-Test.

Ein Snapshot allein bestätigt keine Fokuswechsel oder Tastaturabläufe. Der Timespan-Modus liefert in dieser Version keine Accessibility-Kategorie. Unser Leitfaden zu Cookie-Bannern und Dialogzuständen zeigt die ergänzenden Prüfungen.

Warum brauchen wir zusätzlich Tastaturtests?

Auch ein Scan ohne gemeldete Fehler bestätigt nicht, dass sich jede Aktion mit der Tastatur bedienen lässt. Der separate Fall Tastaturbedienung zeigt das an der Hinzufügen-Aktion: Ein klickbares <div> reagiert auf die Maus, wird aber von Tab übersprungen. Lighthouse erreichte 100, und der direkte axe-Lauf meldete keine Verletzung.

In der verbesserten Tastaturvariante ist die Aktion ein natives <button type="button">. Es ist mit Tab erreichbar und lässt sich mit Enter oder Leertaste auslösen. WCAG 2.1.1 verlangt Tastaturbedienbarkeit; die Ausnahme betrifft Funktionen, die eine vom Bewegungspfad abhängige Eingabe benötigen.

Hier prüfen wir die konkrete Bedienung deshalb manuell. axe enthält auch tastaturbezogene Regeln, etwa scrollable-region-focusable. Daraus folgt aber nicht, dass ein Scan jedes Tastaturproblem erkennt.

So klärst Du unterschiedliche Ergebnisse auf Deiner Seite

Vergleiche zuerst die Testbedingungen. Erst danach lässt sich ein fehlender Befund einer Regelauswahl zuordnen.

1. Versionen festhalten. Notiere Lighthouse, Browser und axe-core. Im Lighthouse-JSON findest Du lighthouseVersion und environment.credits["axe-core"]. Die Version einer separat installierten axe-Erweiterung kann abweichen.
2. Gleichen Inhalt öffnen. Nutze dieselbe URL, Fenstergröße, Sprache, Anmeldung und Cookie-Auswahl. Warte auf die Inhalte, die Du prüfen willst. Ein geschlossener Dialog und ein geöffneter Dialog sind unterschiedliche Testfälle.
3. Regeln vergleichen. Halte Tags, ausdrücklich aktivierte Regeln, Ausnahmen und ausgeschlossene Bereiche fest. Ein auf WCAG 2.1 begrenzter axe-Lauf enthält beispielsweise nicht automatisch target-size aus WCAG 2.2.
4. Ergebnisarten auseinanderhalten. violations sind fehlgeschlagene Regeln. incomplete bedeutet, dass eine weitere Prüfung nötig ist. Bei bewerteten Prüfungen werden solche unentschiedenen Befunde nicht wie festgestellte Verstöße gewertet. Informative Prüfungen können incomplete-Befunde unter ihren gemeldeten Ergebnissen aufführen. Ein Ausführungsfehler ist ebenfalls kein bestandenes Ergebnis.
5. Nach der Änderung denselben Test wiederholen. Vergleiche betroffene Elemente und Regeln. So erkennst Du, ob die Korrektur das konkrete Problem behebt.

Du kannst Lighthouse beibehalten und gezielte axe-Tests für wichtige Zustände ergänzen. Die navable Developer-Workflows bieten einen Einstieg für die Arbeit in der IDE. Prüfe auch dort die verwendeten Tags: Der Local MCP 0.2.0 verwendet standardmäßig WCAG-2.0- und WCAG-2.1-A/AA-Tags, ohne wcag22aa. Eine zweite Engine allein ersetzt ebenfalls keine manuelle Prüfung; dazu gibt es den Beitrag zu Pa11y/HTMLCS.

Wenn Du den gesamten Ablauf planen willst, hilft Dir unser Leitfaden zum Testen einer barrierefreien Website. Wähle eine konkrete Aufgabe, etwa einen Kaufabschluss, und prüfe sie vom ersten Schritt bis zur Bestätigung mit Tastatur und Screenreader.