casoon Lighthouse-/axe-Result-Explainer
Ordnet automatisierten a11y-Tool-Output ein: was eine Regel bedeutet, welche Nutzer betroffen sind, wie man sie behebt. Interner/technischer Blick.
Wann verwenden
- Ein Lighthouse-Report oder axe-Ausgabe soll erklärt und priorisiert werden.
- Regel-IDs/Violations sollen in konkrete Fixes übersetzt werden.
Input
- Tool-Output (Regel-IDs, betroffene Selektoren) oder Report-Pfad.
Prüf-Vorgehen
Pro Violation/Audit:
- Regel-ID auflösen (z.B.
color-contrast,image-alt,label,aria-*). - Bedeutung: was prüft die Regel konkret?
- Nutzerauswirkung: welche Nutzergruppe ist betroffen (Screenreader, Tastatur, Sehschwäche)?
- Fix: konkretes Snippet für den betroffenen Selektor.
- False-Positive-Check: kann die Meldung im Kontext harmlos/falsch sein? (z.B. Kontrast auf verdecktem Element).
Output
Je Regel:
- Regel + Ort: ID + Selektor.
- Bedeutung: 1 Satz.
- Auswirkung: wer ist betroffen.
- Fix: Snippet.
- Priorität: hoch (Sperre) / mittel / niedrig / möglicher False Positive.
Gotchas
- Automatisierte Tools finden nur ~30–40% der Barrieren — manuelle Prüfung bleibt nötig.
- Ein grüner Score ist kein Freibrief;
passed≠ barrierefrei. - Kontrast-Meldungen sind oft False Positives bei Overlays/verdeckten/animierten Elementen.
- Gleiche Regel, mehrere Vorkommen: erst die Ursache im Muster/Component fixen, nicht jedes Vorkommen einzeln.
- Für tiefergehende E2E-Prüfung siehe
playwright(axe-core), für Patternsaccessibility-audit.