Barrierefreiheitsprüfung einrichten
Diese Anleitung zeigt, wie du die optionale CI-Komponente accessibility-checker in deine GitLab-Pipeline einbindest, um deine Webseite automatisch auf Barrierefreiheitsprobleme zu prüfen.
Wie die Prüfung funktioniert
Die CI-Komponente führt pa11y-ci nach dem Build-Schritt aus. pa11y öffnet die fertigen HTML-Seiten in einem Headless-Browser (Chromium), analysiert den gerenderten DOM und gleicht ihn mit den WCAG 2.1 AA-Regeln ab. Gefundene Verstöße werden als SARIF-Report in die Pipeline geschrieben und sind dort einsehbar.
pa11y prüft maschinell prüfbare Kriterien — etwa fehlende Alt-Texte oder Farbkontraste. Ob ein Alt-Text den Bildinhalt sinnvoll beschreibt oder die Tastaturnavigation verständlich geordnet ist, erfordert zusätzlich manuelle Tests.
CI-Komponente einbinden
Ergänze deine .gitlab-ci.yml um die accessibility-checker-Komponente nach dem Build-Schritt:
geben sie hier die URL oder $CI_PAGES_DOMAIN an, wenn die Seite bereits über GitLab Pages erreichbar ist.
Ergebnisse lesen
Nach dem Pipeline-Lauf findest du die Ergebnisse an zwei Stellen:
- Pipeline-Log — pa11y gibt jeden Verstoß direkt aus, inklusive der betroffenen Seite, dem HTML-Element, dem verletzten WCAG-Kriterium und einem Korrekturvorschlag
- Security-Dashboard — der SARIF-Report wird in GitLabs Security-Dashboard eingetragen und erlaubt eine Übersicht über alle offenen Probleme
Häufige Probleme beheben
| Problem | Lösung |
|---|---|
| Bild ohne Alt-Text |  — Alt-Text in eckigen Klammern ergänzen |
| Leere Überschrift | Überschriften müssen Text enthalten |
| Übersprungene Überschriftenebene | Nach # muss ## folgen, nicht ### |
| Fehlender Formular-Label | KERN-UX-Formularkomponenten setzen Labels automatisch — bei eigenem HTML <label for="..."> ergänzen |
| Unzureichender Farbkontrast | Primärfarbe oder Hintergrundfarbe im Theme anpassen; Kontrast mit dem WCAG Contrast Checker prüfen |