Lighthouse-Accessibility-Score

Was diese Prüfung macht

Lässt das Lighthouse-Accessibility-Audit (eine kuratierte Teilmenge der axe-core-Regeln) gegen die Seite laufen und meldet den gewichteten Score. MetricSpot lässt die Prüfung unter 90 durchfallen.

Warum es wichtig ist

Der Score ist ein grobes, aber ehrliches Signal. Lighthouse erkennt nur Probleme, die ein statischer Parser verifizieren kann — ungefähr ein Drittel von WCAG. Was es markiert, ist mit hoher Wahrscheinlichkeit echt, kein False Positive.

Echte Nutzer werden ausgeschlossen. Rund 1 von 5 Besuchern nutzt irgendwann assistive Technologie: Screenreader, reine Tastaturnavigation, Hochkontrast-Modi, Sprachsteuerung. Eine Seite mit einem Accessibility-Score von 60 ist für die meisten von ihnen unbenutzbar.
Rechtliches Risiko. In der EU gilt das European Accessibility Act seit Juni 2025 für öffentlich zugängliche kommerzielle Sites. In den USA hat das DOJ ausdrücklich erklärt, dass ADA Title III auch Websites abdeckt. Seiten mit durchfallendem Score sind ein beliebtes Ziel von Abmahnklagen.
SEO und KI. Googles Page-Experience-Signale beziehen Accessibility-nahe Metriken ein. KI-Crawler parsen über denselben DOM-Baum, den Screenreader verwenden — kaputte Semantik schadet der Extraktion.

Wie du es behebst

Öffne Lighthouse (Chrome DevTools → Tab Lighthouse → Accessibility) und lass es gegen die durchfallende URL laufen. Der Report listet jedes fehlschlagende Audit nach Schwere gruppiert auf und markiert die betroffenen DOM-Knoten.

Konzentriere dich zuerst auf die am höchsten gewichteten Punkte — Lighthouse gewichtet Audits nach Wirkung, nicht nach Anzahl:

Farbkontrast (color-contrast) — Text ≥ 4.5:1, große Schrift ≥ 3:1. Nutze ein Tool wie Stark oder den Kontrast-Indikator der DevTools.
Bild-Alt-Texte (image-alt) — jedes <img> braucht ein alt-Attribut, auch leer bei dekorativen Bildern. Siehe Alt-Texte für Bilder.
Formular-Labels (label) — jedes Input braucht ein explizites <label for="…">. Siehe Formular-Labels.
Dokumentsprache (html-has-lang) — <html lang="de"> an der Wurzel. Siehe Seitensprache deklarieren.
Linktext (link-name) — kein “hier klicken”, keine leeren <a>. Siehe Beschreibender Linktext.

Lass axe-core in CI laufen, um Regressionen zu fangen:

bun add -d @axe-core/playwright

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("home page is accessible", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

Manuelle Prüfungen, die Lighthouse nicht macht. Tabbe einmal von oben nach unten durch die Seite — ist die Fokus-Reihenfolge logisch? Ist der Fokusring sichtbar? Aktiviere VoiceOver (Cmd+F5 auf macOS) oder NVDA (Windows) und lies eine Seite einmal komplett vor. Lighthouse 100 ist der Boden, nicht die Decke.

Häufig gestellte Fragen

Warum war mein Score beim erneuten Lauf so unterschiedlich?

Lighthouse läuft in einem Headless-Chrome mit gedrosselter CPU. Netzwerk-Rauschen, Ad-Skripte und das Timing des Consent-Banners können den Score um 5–10 Punkte verschieben. Lass drei Läufe machen und nimm den Median; behandle den Trend als Wahrheit, nicht den Einzelwert.

Lighthouse zeigt 100 — bin ich fertig?

Nein. Lighthouse auditiert etwa 30 % von WCAG. Die anderen 70 % (logische Lesereihenfolge, Fehler-Recovery-Flow, Fokus-Management, Bedeutung, die nur über Farbe vermittelt wird) brauchen manuellen Review. Ein 100er-Score heißt: die automatisierte Baseline ist sauber; das manuelle Review kommt obendrauf.

Wo kommt der Score im Audit her?

MetricSpot ruft die Lighthouse-Engine während des Audits auf und speichert den Score. Wenn der Lauf scheitert (Seite hinter Login, blockt Headless-Browser oder läuft in einen Timeout), siehst du stattdessen einen separaten Befund Lighthouse Accessibility nicht verfügbar.