accessibility
Lighthouse-Accessibility-Fehler
Zählt die konkreten Accessibility-Audits, die Lighthouse gemeldet hat. Die High-Leverage-Liste — die meisten Fehler sind Einzeiler in Markup oder CSS.
Was diese Prüfung macht
Zählt, wie viele Lighthouse-Accessibility-Audits auf der Seite fehlgeschlagen sind. Lighthouse führt im Hintergrund axe-core aus und gruppiert die Ergebnisse in pass/fail/manual. Diese Regel meldet die Fail-Anzahl und listet sie auf — der Lighthouse-Accessibility-Score ist die Schlagzeile, diese Regel ist die To-do-Liste.
Typische Auffälligkeiten, die MetricSpot zeigt:
color-contrast— Text unterhalb des AA-Kontrastverhältnisses 4,5:1.image-alt—<img>ohnealt(anders als Bild-Alt-Text-Qualität, die die Aussagekraft bewertet).link-name/button-name— interaktive Elemente ohne zugänglichen Namen (Icon-only-Buttons sind der Klassiker).label— Formularsteuerelemente ohne zugehöriges<label>.html-has-lang/html-lang-valid— abgedeckt durch Seitensprache deklarieren.document-title— leerer oder fehlender<title>.aria-*— ungültige Rollen, fehlende Pflichtattribute oderaria-hiddenauf fokussierbaren Elementen.list/listitem—<li>außerhalb eines<ul>/<ol>-Parents.
Warum es zählt
Lighthouse-Fehler sind die behebbare Hälfte der Barrierefreiheit. Jedes Audit in dieser Liste lässt sich mechanisch von einem Build-Agenten verifizieren — kein menschliches Urteil nötig. Es sind auch die Audits, die am wahrscheinlichsten in einer rechtlichen Beschwerde auftauchen: Kontrast und fehlende Form-Labels sind die beiden häufigsten Punkte in US-amerikanischen ADA-Webaccessibility-Klagen, und das EU-Barrierefreiheitsgesetz (in Kraft seit Juni 2025) liest dieselbe Checkliste.
Diese Zahl auf null zu bekommen, macht eine Seite nicht vollständig WCAG-konform — etwa ein Drittel der WCAG-2.1-AA-Kriterien erfordert manuelle Prüfung — aber es räumt die einfachsten Einwände aus dem Weg.
So behebst du es
Lies die Fehler der Reihe nach. Jeder Lighthouse-Fehler enthält ein “Failing elements”-Snippet — das ist dein Ausgangspunkt.
Die Liste pro Audit ansehen:
- Lighthouse CLI / DevTools — Audit laufen lassen, zu “Accessibility” scrollen, jeden roten Eintrag aufklappen, um die Element-Liste zu sehen.
- PageSpeed Insights —
pagespeed.web.dev/?url=<deine-url>liefert dieselben Audits mit Element-Selektoren. - DevTools → Issues-Panel — Chrome 109+ zeigt axe-core-Issues live beim Browsen.
Verdrahte es in CI. Verlass dich nicht darauf, dass Menschen Lighthouse klicken. Pack axe-core in deine E2E-Suite:
bun add -D @axe-core/playwright axe-playwright
// e2e/a11y.spec.ts
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";
test("home has no detectable a11y violations", async ({ page }) => {
await page.goto("/");
const results = await new AxeBuilder({ page })
.withTags(["wcag2a", "wcag2aa", "wcag21aa"])
.analyze();
expect(results.violations).toEqual([]);
});
Für React-/Next-/Astro-Builds füge zusätzlich eslint-plugin-jsx-a11y hinzu, um die offensichtlichen Fälle bereits beim Linten zu fangen.
Die Top-5-Einzeiler-Fixes:
| Fehler | Fix |
|---|---|
color-contrast | Vorder- oder Hintergrund anheben, bis das Verhältnis 4,5:1 (3:1 für Text ab 18pt) erreicht. Der DevTools-Colorpicker zeigt das Verhältnis live. |
image-alt | alt="..." setzen. Für rein dekorative Bilder alt="" (leer, nicht weggelassen). Siehe Bild-Alt-Text. |
button-name | Icon-only-<button>s brauchen aria-label="Menü schließen". Eingebettete SVG-Icons brauchen aria-hidden="true". |
link-name | Wie Buttons. Icon-Links mit beschreibendem Text oder aria-label versehen. Siehe aussagekräftiger Linktext. |
label | <input> in <label> wickeln oder <label for="id"> + id="id" nutzen. Siehe Formular-Labels. |
Wenn der Score statt einer Zahl n/a zeigt, siehe Lighthouse-Accessibility nicht verfügbar — das Audit ist gar nicht gelaufen.
Häufig gestellte Fragen
Komme ich auf 100, wenn ich alle Fehler behebe?
Du landest meist im hohen 90er-Bereich. Der Lighthouse-Accessibility-Score ist gewichtet, aber nicht linear — color-contrast zählt schwer, andere leicht. Die restlichen Punkte stammen oft aus manuellen Prüfungen (Fokus-Reihenfolge, Screenreader-Erzählung), die das automatisierte Audit als “Additional items to manually check” listet.
Kann ich Audits unterdrücken, mit denen ich nicht einverstanden bin?
Ja, über das skipAudits-Array der Lighthouse-Config — aber überleg gut, bevor du unterdrückst. Der klassische False-Positive ist color-contrast auf Text über Hero-Bildern — fix den Kontrast (Overlay oder solider Hintergrund) statt das Audit zu überspringen.
Wie unterscheidet sich das von axe-core in DevTools?
Eigentlich kaum. Lighthouse bündelt axe-core und führt eine Teilmenge seiner Regeln aus. Die axe-DevTools-Extension läuft das volle Set, daher siehst du dort eventuell mehr Issues — die zusätzlichen sind meist mit best-practice getaggt und nicht WCAG-pflichtig.
Quellen
Zuletzt aktualisiert 2026-05-11