Die Barrierefreiheit, die nur einmal im Jahr in einer einmaligen manuellen Überprüfung überprüft wird, lässt fast immer schnell nach – jedes kleine Code-Update kann etwas zerstören, das bereits behoben wurde. Die Lösung: Integrieren Sie Barrierefreiheitstests als automatisierten Schritt in den Entwicklungsprozess selbst (CI/CD), damit Probleme erkannt werden, bevor sie in die Produktion gelangen. In diesem Artikel wird erklärt, wie.

Kurz gesagt – was dieser Artikel behandelt

  1. Warum eine einmalige Prüfung nicht ausreicht
  2. Was automatisierte Tools in der CI/CD-Pipeline erfassen können
  3. Wo noch manuelle Tests erforderlich sind
  4. Wie man es in die Praxis umsetzt

Warum eine einmalige Prüfung nicht ausreicht

Ein Entwicklungsteam, das jede Woche oder manchmal sogar jeden Tag Updates versendet, kann sich nicht auf eine jährliche Prüfung der Barrierefreiheit verlassen, um die fortlaufende Einhaltung der Vorschriften sicherzustellen. Eine neue Komponente, die ohne Berücksichtigung der Barrierefreiheit hinzugefügt wird, oder eine CSS-Änderung, die versehentlich den Kontrast verringert, kann die bereits behobene Barrierefreiheit beeinträchtigen – und niemand bemerkt es, bis ein Benutzer oder eine Beschwerde es offenbart. Das gleiche Prinzip gilt auch für Dokumente – siehe unseren Leitfaden aufMapping häufiger Fehler.

Was automatisierte Tools in der CI/CD-Pipeline erfassen können

Tools wie axe-core, Pa11y oder Lighthouse CI können automatisch bei jeder Pull-Anfrage oder vor jeder Bereitstellung ausgeführt werden – innerhalb von Sekunden überprüfen sie Dinge wie: Farbkontrast, falsche oder doppelte ARIA-Tags, fehlender Alt-Text, fehlende Formularbeschriftungen und falsche Überschriftenreihenfolge. Wenn die Prüfung fehlschlägt, wird die Zusammenführung der Pull-Anfrage automatisch blockiert – genau wie bei einer regulären Codeüberprüfung oder einem fehlgeschlagenen Komponententest.

💡 Praxistipp

Starten Sie einige Wochen lang im „Warnmodus“ (nicht blockierend), um zu sehen, wie viele Probleme bereits in der Codebasis vorhanden sind, und wandeln Sie die Prüfung erst nach einer ersten Bereinigung in einen Bereitstellungsblocker um – so bleibt das Team nicht am ersten Tag mit Hunderten von Fehlern „stecken“.

Wo noch manuelle Tests erforderlich sind

Genau wie beim Testen von Dokumenten erkennen automatisierte Tools in der CI/CD-Pipeline klare strukturelle Probleme, können aber nicht die tatsächliche Benutzererfahrung beurteilen: ob die Tastaturnavigation sinnvoll ist, ob ein Screenreader auf der Seite „eine zusammenhängende Geschichte erzählt“ oder ob eine benutzerdefinierte Komponente (wie ein Karussell oder ein Modal) im realen Einsatz wirklich verwendbar ist. Deshalb lohnt es sich, die laufenden automatisierten Kontrollen mit einer regelmäßigen manuellen Prüfung zu kombinieren – zum Beispiel vierteljährlich.

Wie man es in die Praxis umsetzt

  1. Wählen Sie ein Testtool, das zu Ihrem Technologie-Stack passt (Axe-Core für die meisten JavaScript-Projekte, Lighthouse CI für browserbasierte Projekte).
  2. Führen Sie es als Schritt in Ihrer CI-Pipeline aus – normalerweise als GitHub-Aktion, einen GitLab-CI-Job oder einen gleichwertigen Schritt in dem von Ihnen verwendeten CI/CD-Tool.
  3. Legen Sie einen klaren Fehlerschwellenwert fest (z. B. keine „kritischen“ Probleme pro Axe-Core), bevor die Prüfung zum Blocker wird.
  4. Schützen Sie auch Ihre PDF-Dateien: Wenn Ihre Organisation automatisch Dokumente generiert (Rechnungen, Berichte), sollten Sie darüber nachdenken, diese auch automatisch zu scannen, als Teil des Veröffentlichungsprozesses.

Möchten Sie auch automatisierte PDF-Tests in Ihren Prozess integrieren?

Unser Tool scannt PDF-Dateien und gibt jedem Dokument eine Barrierefreiheitsbewertung – Sie können es als regelmäßige Prüfung parallel zu Ihrem CI/CD-Prozess durchführen.

Scannen Sie Ihre Website kostenlos ←

Nach dem Scannen können Sie die gefundenen Dokumente auch direkt und kostenlos über zugänglich machenAccessiDoc.