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> ohne alt (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 oder aria-hidden auf 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 Insightspagespeed.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:

FehlerFix
color-contrastVorder- 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-altalt="..." setzen. Für rein dekorative Bilder alt="" (leer, nicht weggelassen). Siehe Bild-Alt-Text.
button-nameIcon-only-<button>s brauchen aria-label="Menü schließen". Eingebettete SVG-Icons brauchen aria-hidden="true".
link-nameWie 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