Bist du in Projekten, in denen Barrierefreiheit zwar gewollt ist, aber keine Zeit oder Budget dafür bereitsteht? Wo das Team vielleicht noch wenig Erfahrung mit barrierefreiem Code hat oder Flüchtigkeitsfehler in die Produktion durchrutschen?
Ich selbst finde mich oft in genau diesen Situationen wieder. Über die Zeit haben sich für mich einige technische Lösungen bewährt, die zumindest ein grundlegendes Sicherheitsnetz spannen – und das fast nebenbei.
Ein schöner Nebeneffekt: Auch die Projektleitung war darüber bislang immer glücklich, weil sie die beachtete Barrierefreiheit im Reporting gut darstellen konnten, ohne dass sie dafür extra Aufwände einplanen musste :)
1. Die Programmierumgebung (IDE) als erster Filter
IDEs haben im letzten Jahr zunehmend mehr Checks für Barrierefreiheit integriert – entweder direkt oder über Plugins.
Man muss sie nur aktivieren bzw. beachten. IntelliJ / WebStorm haben diese mittlerweile von Haus aus mitgeliefert, für VS Code gibt es z. B. den axe Accessibility Linter.
Da wir hier direkt in der IDE sind, ist dieser Überprüfungsschritt stark von den einzelnen Personen abhängig - insbesondere wenn die Leute unterschiedliche IDEs im Projekt verwenden. Aber hier mal die Einstellungen zum Einschalten heraussuchen, ein paar Plugins auszuprobieren und die IDE so konfigurieren, dass diese Accessibility-Probleme direkt inline als Warnung ausgegeben werden können, all das ist in ein paar Minuten machbar. Und in einer Kaffee- oder Teepause kann man den Teammitgliedern dann davon erzählen und ihnen sagen, wie sie das auch aktivieren können ;)
2. Linting für die statische Codeanalyse
ESLint ist für mich seit langem Standard für Projekte, um ein einheitliches Codebild zu erzeugen. Neuerdings gibt es dafür auch Lintingregeln für Accessibility-Checks – auch bereits als fertige Sets zusammengestellt, wie z. B. jsx-a11y/recommended für NextJS oder @angular-eslint/template/accessibility für Angular. Damit braucht es
grob gesprochen nur das Installieren einer neuen Dependency und das Hinzufügen einer Zeile bei den ESLint-Regeln.
Bevorzugt kombiniere ich das mit Husky zum Erstellen von Commit Hooks. Damit können sämtliche Lintingregeln schon vor dem Commit oder Push überprüft werden – und damit wird die statische Codeanalyse für die Barrierefreiheit gleich mitgemacht.
Diese Art von statischer Codeanalyse hat zwar ihre engen Grenzen, aber sie funktioniert konsistent für alle Teammitglieder, unabhängig von deren IDE-Konfiguration oder Arbeitsweise. Diese Checks sind hervorragend geeignet, um strukturelle Fehler wie fehlende Attribute (z. B. lang) oder ungültige ARIA-Attribute (z. B. auf falschen Elementen oder mit fehlenden IDs, auf die sie verweisen) abzufangen. Ihre Grenze liegt jedoch bei der inhaltlichen Prüfung, etwa ob die Hierarchieebenen von Überschriften stimmen oder ob ein alt-Text kontextuell korrekt ist.
3. SonarQube als Qualitäts-Dashboard
Vielleicht ist in dem Projekt auch SonarQube im Einsatz? Wenn ja, dann versuche, ob du dort die Regeln für die Barrierefreiheit aktivieren (lassen) kannst. SonarQube ist gut geeignet, um alle Accessibility-Probleme zusammen mit anderen Qualitätsmetriken in einem Dashboard zu sammeln. Hierbei kannst du auch Qualitygates konfigurieren oder bekannte Probleme für später markieren. Damit hat auch die Projektleitung eine zentrale Übersicht über die Codequalität.
Falls nicht, dann ist es nicht weiter schlimm: Es gibt in meiner Erfahrung keinen starken Mehrwert für die Codequalität zu den zuvor genannten Lintingregeln, da beides primär auf statischer Codeanalyse basiert.
4. Unit Tests als Funktionscheck mit Grenzen
Obwohl Unit Test Frameworks wie Jest in Kombination mit Tools wie jest-axe die Möglichkeit bieten, Barrierefreiheitstests auf Komponentenebene zu integrieren, ist dieser Ansatz meiner Erfahrung nach oft mit hohem Aufwand bei geringem Ertrag verbunden.
Das Kernproblem liegt dabei in der Testumgebung selbst: Das vereinfachte HTML-DOM von Jest (jsdom) bildet kein natives Browser-DOM ab. Dies führt dazu, dass dynamische oder browserabhängige Aspekte der Barrierefreiheit, wie z. B. Fokus-Management, Kontraste oder komplexe ARIA-Interaktionen, nicht zuverlässig getestet werden können. Daher ist es
meistens sinnvoller, stattdessen gleich End-to-End Tests zu schreiben (wobei Unit Tests für berechnete ARIA-Attribute trotzdem nicht verkehrt sind ;)
5. End-to-End (E2E) Tests als Realitätscheck im Browser
Gibt es im Projekt E2E Tests, egal ob von Entwickler:innen oder Tester:innen verwaltet, können mittlerweile relativ einfach Accessibilitytests in die bestehenden Tests integriert werden. In codebasierten Frameworks wie Playwright oder Cypress kann die axe-core Bibliothek direkt eingebunden werden. Auch UI-basierte Lösungen wie Tosca bieten entsprechende Funktionen an.
Das einfachste Vorgehen ist, in die bestehenden Tests zu ausgewählten Zuständen der Anwendung (z. B. direkt nach Seitenaufruf, Formular fehlerhaft ausgefüllt, Bestätigungsdialog geöffnet) die Anweisung hinzuzufügen, dass von diesem Zustand eine Überprüfung der Barrierefreiheit gemacht werden soll. Da E2E Tests in einer realistischen Browserumgebung ausgeführt werden, untersuchen sie das tatsächlich gerenderte HTML in seinem Zusammenspiel. Dies ermöglicht es, dynamische Probleme und Fehler zu finden, die nur im konkreten Anwendungszustand auftreten, wodurch die meisten automatisierbar feststellbaren Probleme der Barrierefreiheit gefunden werden.
CI/CD Pipelines als Grundgerüst
Zuvor habe ich Commit Hooks zur automatisierten Durchführung von Qualitätschecks angesprochen. Da diese lokal laufen, können sie von Entwickler:innen übersprungen werden. Damit ist es auch wichtig, dass sämtliche der genannten Checks auch immer in der CI/CD Pipeline ausgeführt werden: Und dass diese auch fehlschlägt, wenn Probleme festgestellt werden ;)
Die Grenzen der Automatisierung kennen
Gerade bei schon bestehenden, älteren Projekten werden bei der Einführung der genannten Checks vermutlich zahlreiche Probleme der Barrierefreiheit festgestellt werden. Hier wird es sich nicht vermeiden lassen, Fehlertickets zu erstellen (und dafür entsprechende Zeit oder Budget zu verwenden). Bis dahin bieten aber all die genannten Methoden Wege an, um spezifische gefundene Probleme zu ignorieren (z. B. über spezielle Kommentare im Code oder über Konfigurationen).
Wenn die Checks keine Fehler mehr melden, heißt das allerdings nur: Es gibt keine automatisch erkennbaren Barrieren mehr. Schätzungsweise decken diese Tools nämlich nur etwa ein Drittel der tatsächlichen Fehler ab, und selbst das nur, wenn man sämtliche Anwendungszustände via E2E Tests überprüft.
Für den Rest sind aktuell manuelle Überprüfungen unumgänglich – und dafür braucht es dann Zeit und Budget für die Durchführung und die Behebung. Und wenn ihr schon dabei seid, dann überprüft nicht nur die WCAG- und EN-Kriterien, sondern testet auch, ob die Usability für Menschen mit assistiven Technologien passt – denn das ist das, worauf es vor allem ankommt :)
