Automatisierte Barrierefreiheitstests: Drei Ansätze und zusätzliche Überlegungen

Barrierefreiheit ist längst keine Option mehr, sondern ein Muss. Gesetzliche Vorgaben wie die BITV 2.0 (für den öffentlichen Dienst), das Barrierefreiheitsstärkungsgesetz (BFSG) und der European Accessibility Act verlangen die barrierefreie Gestaltung digitaler Anwendungen. Neben der Einhaltung dieser Anforderungen bietet Barrierefreiheit auch Vorteile für alle Nutzer, da barrierefreie Anwendungen oft intuitiver und einfacher zu bedienen sind.
Unabhängig davon, ob Projekte nach dem Wasserfallmodell, hybrid oder agil entwickelt werden, sollte Testautomatisierung eine sinnvolle Ergänzung zu manuellen Tests darstellen. Testautomatisierung kann Kapazitäten für den manuellen Test erweitern. So können diverse Basistests, die sonst jedes Mal manuell durchgeführt werden müssten, nach jedem Einchecken im Code automatisiert geprüft werden. Die frei gewordenen Kapazitäten lassen sich für die Prüfungen nutzen, in welchen die Testautomatisierungen noch nicht unterstützen können. Die Nutzung eines Screenreaders unter realen Bedingungen kann dabei sehr hilfreich sein. Um die Vorteile der Testautomatisierung nutzen zu können, sollte diese aber auch stabil laufen und der Wartungsaufwand geringer als die gewonnene zusätzliche Zeit sein.
Voraussetzungen für automatisierte Tests
Die beschriebenen Ansätze für Webanwendungen setzen eine funktionsfähige CI/CD-Pipeline voraus, die beispielsweise mit GitLab, Jenkins oder GitHub Actions betrieben wird. Sollten solche Pipelines nicht vorhanden sein, lassen sich die Tests auch lokal ausführen. Für die ersten beiden Ansätze ist zudem Node.js in Version 16 oder höher erforderlich.
Ansatz 1: Barrierefreiheitsprüfungen mit axe-core CLI
Deque Systems bietet mit axe-core eine Accessibility Rules Engine auf Open-Source-Basis an. Diese dient als Grundlage für zahlreiche kostenfreie und kommerzielle Lösungen.
Installation
Die CLI-Version von axe-core kann mit folgendem Befehl installiert werden:
npm install -g @axe-core/cli
Anwendung
Nach der Installation wird die Prüfung über das Terminal gestartet:
axe duckduckgo.com
Dieser Befehl führt eine Analyse der angegebenen URL durch. Es können mehrere Seiten nacheinander geprüft werden, indem die URLs beispielsweise in einem Skript übergeben werden. Tools wie Scrapy ermöglichen es, URLs automatisiert zu sammeln und an axe-core zu übergeben.
Anwendungsbereich und Grenzen
Dieser Ansatz eignet sich besonders für die initiale Prüfung statischer Seiten. Dynamische Inhalte wie Fehlernachrichten, eingebettete Videos oder Toast-Nachrichten lassen sich damit nicht überprüfen. Für solche Tests bietet der zweite Ansatz bessere Möglichkeiten.
Ansatz 2: Integration von axe-core mit Cypress
Frameworks wie Cypress, Playwright und Selenium sind bewährte Werkzeuge für automatisierte GUI-Regressionstests. Die Integration von axe-core in Cypress mithilfe von cypress-axe ermöglicht umfassendere Barrierefreiheitsprüfungen.
Installation
Die benötigten Pakete können über npm installiert werden:
npm install cypress cypress-axe --save-dev
Integration
In den Tests müssen neben dem Import die Methoden cy.injectAxe() und cy.checkA11y() verwendet werden:
import 'cypress-axe';
cy.injectAxe();
cy.checkA11y();
Vorteile
Mit Cypress lassen sich auch dynamische Inhalte testen. Darüber hinaus können einzelne Regeln aktiviert oder deaktiviert werden. Falls Barrierefreiheitsprobleme auf ein UI-Framework zurückzuführen sind, können betroffene Bereiche temporär ausgeschlossen werden. Solche Ausschlüsse sollten jedoch als technische Schulden dokumentiert und später bearbeitet werden.
Ansatz 3: Low-Code-Lösungen mit QF-Test
Eine gute Testautomatisierung zeichnet sich durch Modularität und Wartbarkeit aus. Low-Code-Ansätze ermöglichen die Erstellung und Wartung von Tests ohne tiefgehende Programmierkenntnisse. QF-Test ist ein kommerzielles Werkzeug, das für eine begrenzte Zeit kostenlos getestet werden kann. Ab der Version 9.0.0 sind Barrierefreiheitstests über eine eigene Integration von axe-core verfügbar. Diese wurde im Januar 2025 veröffentlicht.
Eigenschaften
- Technologieübergreifend: Unterstützung von Java-, Web- und Windows-Anwendungen
- Erweiterte Tests: Zusätzliche Prüfungen wie Fokus- und Kontrasttests, die über die Möglichkeiten von axe-core hinausgehen
- Modularität: Tests können nach dem DRY-Prinzip strukturiert werden, um redundanten Code zu vermeiden.
Während der QF-Test ab der Version 9.0.0 speziell auf Barrierefreiheitsprüfungen eingeht, bietet eine vergleichbar komplexe Lösung wie Tricentis Tosca aktuell keine spezifischen Funktionen in diesem Bereich.
Screenshot aus der Entwicklerversion
Der Hersteller QFS hat eine Vorabversion für diesen Fachartikel bereitgestellt. Hier lässt sich erkennen, wie die gefundenen Barrierefreiheitsprobleme visuell direkt an der betroffenen Stelle angezeigt werden. Zusätzlich ist die Prüfung des Kontrastverhältnisses bei einem Bild dargestellt.
Weitere Ansätze für automatisierte Barrierefreiheitsprüfungen
Cloud-Anbieter wie BrowserStack bieten ebenfalls Tools für Barrierefreiheitsprüfungen an. Diese Lösungen eignen sich besonders für Cross-Browser-Tests. Allerdings können datenschutzrechtliche Anforderungen, insbesondere im öffentlichen Dienst, den Einsatz erschweren.
Weitere Testframeworks wie Playwright, Puppeteer, Selenium oder TestCafe bieten ebenfalls Integrationen mit axe-core an und können abhängig von den Projektanforderungen verwendet werden.
Fazit zu automatisierten Barrierefreiheitstests
Automatisierte Barrierefreiheitstests sollten nicht isoliert betrachtet werden, sondern als Bestandteil eines kontinuierlichen Entwicklungsprozesses. Die vorgestellten Ansätze bieten unterschiedliche Möglichkeiten, Barrierefreiheit effizient zu prüfen. Während axe-core über die CLI schnelle erste Ergebnisse liefert, ermöglicht cypress-axe die Prüfung dynamischer Inhalte. Low-Code-Lösungen wie QF-Test erweitern die Möglichkeiten und erleichtern den Zugang zu Testautomatisierung. Die Auswahl des richtigen Werkzeugs hängt letztlich von den Anforderungen des Projekts ab.
Shift-Left: Barrierefreiheit durch a11y-Linter
Bereits in der frühen Phase der Software-Entwicklung können Werkzeuge eingesetzt werden, um Barrierefreiheitsvorgaben direkt umzusetzen. Dieser Ansatz, bekannt als "Shift-Left", gewinnt zunehmend an Bedeutung. Es gibt inzwischen eine Vielzahl von Tools, die diesen Ansatz unterstützen. Einige davon werden im Folgenden vorgestellt.
ESLint mit Accessibility-Regeln
In vielen Angular-Projekten wird ESLint bereits als Standardwerkzeug für die Codeanalyse verwendet. Es bietet sich daher an, auch die Accessibility-Regeln von ESLint zu aktivieren. Sobald das Accessibility-Plugin integriert ist, werden Verstöße gegen diese Regeln direkt im Code als Fehler angezeigt.
Vorteile
- Frühzeitige Erkennung: Probleme werden bereits in der Entwicklungsphase identifiziert.
- Effiziente Fehlerbehebung: Entwickler können Barrierefreiheitsprobleme unmittelbar lösen.
- Nahtlose Integration: Da ESLint häufig bereits im Einsatz ist, entsteht keine zusätzliche Lernkurve.
Dieser Ansatz ermöglicht es dem Entwicklungsteam, Barrierefreiheit von Anfang an in den Workflow zu integrieren, ohne zusätzliche Tools einführen zu müssen.
SonarLint mit Accessibility-Regeln
Ein weiteres bewährtes Tool ist SonarLint, das oft zusammen mit SonarQube verwendet wird. Auch hier können Accessibility-Regeln aktiviert werden, die bei der Codeanalyse helfen. Während ESLint die Barrierefreiheitsprobleme direkt im Editor erkennt, identifiziert SonarLint diese meist im Rahmen des DevOps-Workflows. Dadurch erfolgt die Problemerkennung typischerweise etwas später. Aus diesem Grund ergänzen sich ESLint und SonarLint gut, da sie in unterschiedlichen Phasen des Entwicklungsprozesses eingesetzt werden.
axe Accessibility Linter
Der axe Accessibility Linter ist eine weitere Option, die als Plugin für Entwicklungsumgebungen wie IntelliJ und WebStorm verfügbar ist. Er basiert auf den Web Content Accessibility Guidelines (WCAG) und zeigt Probleme direkt im Editor an. Die WCAG-Regeln des axe Linters können projektspezifisch angepasst werden, um individuelle Anforderungen zu berücksichtigen.
WAVE Accessibility Linter
Der WAVE Accessibility Linter ist für einige verbreitete Browser als Plugin erhältlich und richtet sich nicht nur an Entwickler, sondern auch an andere Teammitglieder. Er analysiert den HTML-Code und zeigt Barrierefreiheitsprobleme direkt im Browser an der entsprechenden Stelle der Anwendung.
Vorteile
- Benutzerfreundlichkeit: Die visuelle Darstellung der Probleme erleichtert die Nutzung auch für Personen ohne technische Vorkenntnisse.
- Fehlerbehebung direkt im Kontext: Zusätzlich kann der Code direkt eingeblendet werden, um Probleme effizient zu beheben.
Die vorgestellten Tools können einzeln oder parallel verwendet werden. Durch ihre unterschiedlichen Schwerpunkte ergänzen sich diese – zum Beispiel ESLint für die Codeanalyse und WAVE für die visuelle Darstellung der Problematiken. Es ist bei weiteren Prüfungen wichtig darauf zu achten, dass sich die aktivierten Regeln nicht gegenseitig ausschließen.
Praxisbeispiel: Barrierefreiheit durch Kombination von ESLint und WAVE
Ein Beispiel für den Einsatz von ESLint und WAVE ist die Prüfung eines Button-Elements. Dieses enthält ein Icon, welches zum Ein- oder Ausklappen einer Tabellenzeile verwendet wird. Da der Button keinen Text enthält, könnte ein Screenreader keine zusätzlichen Informationen liefern und somit nicht korrekt navigiert werden. ESLint zeigt direkt im Editor eine Fehlermeldung und liefert eine Erklärung, warum das Fehlen eines Inhalts problematisch ist.
- WAVE markiert denselben Fehler visuell im Browser und erleichtert so auch Nicht-Entwicklern die Identifikation des Problems.
Das Problem lässt sich durch Hinzufügen eines aria-labels lösen. Dadurch wird der Button für Screenreader zugänglich, ohne das visuelle Design zu ändern.
Der Button hat keinen Inhalt. ESLint liefert zusätzlich eine ausführliche Beschreibung dieser Regel und erklärt, warum dies aus Barrierefreiheitssicht ein Problem darstellt.
Das WAVE-Tool erkennt dieselbe Regel und zeigt eine entsprechende Fehlermeldung direkt im Browser an der betroffenen Stelle des Buttons. Für die Nutzung von WAVE sind keine Programmierkenntnisse erforderlich. Dadurch können alle Teammitglieder, die das Tool verwenden, Barrierefreiheitsprobleme erkennen und diese an das Entwicklungsteam weiterleiten.
Der so gefundene Fehler lässt sich sehr leicht durch Hinzufügen eines aria-labels lösen – ein Schritt näher an barrierefreiem Code.
Automatisierte Barrierefreiheitstests: Fazit zum Shift-Left-Ansatz
Ansätze wie die Verwendung von a11y-Lintern ermöglichen es, Barrierefreiheitsprobleme frühzeitig zu erkennen und effizient zu beheben. Tools wie ESLint, SonarLint, axe Accessibility Linter und WAVE bieten unterschiedliche Schwerpunkte und ergänzen sich gut. Die Einbindung der vorgestellten Werkzeuge in den Entwicklungsprozess kann dabei unterstützen, barrierefreie Software von Anfang an sicherzustellen.
Barrierefreiheit auf den diesjährigen IT-Tagen
Spannende Vorträge und Workshops zum Thema Barrierefreiheit erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
Neuen Kommentar schreiben