Autor: Jakub Kratochvil
Fragt man Kolleg:innen in der Softwareentwicklung wie weit ihre Projekte sind, hört man häufig: „Wir sind fast fertig!“ Mittlerweile hört man oft auch: „Klar, wir sind fast fertig, es muss nur noch der Barrierefreiheitstest durch die externe Prüfstelle durchgeführt werden.“
Und dann findet dieser Barrierefreiheitstest statt. Beim ersten Anlauf werden bereits viele Befunde festgestellt: Nicht alle Auflösungen funktionieren, Screenreader lesen nicht richtig vor, und so weiter. Im nächsten Sprint wird dann fleißig entwickelt, der Test wird wiederholt. Die Anzahl der Findings wird zwar niedriger – oft ist aber ein dritter oder sogar vierter Anlauf notwendig, bis das erwünschte Testat erreicht wird. Erschwerend kommt hinzu, dass die Dauer der Feedbackschleife bei Barrierefreiheitstests sehr lang ist. Häufig muss ein separater externer Dienstleister beauftragt werden, der Test muss in bestimmten Umgebungen oder in einem Usability-Labor durchgeführt werden. Es ist nicht unüblich, dass zwischen den zwei Testläufen mehrere Wochen oder gar Monate vergehen. Das resultiert in Projektverzögerungen, aus fast fertig wird nicht ganz fertig.
Bedeutung von Barrierefreiheit
In der öffentlichen Verwaltung ist Barrierefreiheit seit langer Zeit verpflichtend. Das Barrierefreiheitsstärkungsgesetz (BITV) aus dem Jahre 2022 erweitert die Pflichten auf Telekommunikationsdienste, Bankdienstleistung sowie Personenbeförderungsdienste und Onlinehandel. Barrierefreiheit soll aber nicht nur als Erfüllung einer Pflicht verstanden werden.
In Deutschland leben aktuell über 7,5 Millionen Personen mit einer Behinderung, die oftmals aus dem Angebot von Organisationen ausgeschlossen werden. Die Integrationsarbeit an dieser Stelle trägt nicht nur zur Inklusion, sondern auch zur höheren Erfüllung von Corporate Social Responsibility Kriterien bei.
BITV in der Alten Welt
Im klassischen sequenziellen Entwicklungszyklus nach V-Modell XT ist die Überprüfung der Barrierefreiheit typischerweise Teil des Abnahmetests, also in der letzten Phase des Entwicklungszyklus verortet – kurz vor Inbetriebnahme. Die Behebung der Fehler in dieser Phase ist äußerst aufwändig und kostenintensiv.
Manuelle BITV in der Agile Welt
Die agile Entwicklung sieht vor, dass nach jedem Sprint (im 2- bis 4-wöchigen Takt) ein Releasekandidat produziert wird. Ein manueller BITV Testlauf nimmt aber oft 2 Wochen in Anspruch. Was passiert? Ohne Automation wird oft darauf verzichtet, im Sprint auf Barrierefreiheit zu testen. Wenn ein großes Release bevorsteht, wird das Produkt als fast fertig an die Abteilung für Barrierefreiheit ausgeliefert und wir haben das eingangs aufgeführte Dilemma.
Damit wird der Product Owner mit der Wahl konfrontiert, entweder ein nicht BITV-konformes System produktiv zu setzen und die damit verbundenen Risiken und Strafen zu riskieren oder noch weitere Projektverzögerungen in Kauf zu nehmen.
Warum wird BITV zum Flaschenhals in Projekten?
Der Grundsatz des frühen Tests ist in der IT-Branche für funktionale Tests weit bekannt und praktiziert. Nach ISTQB geht man von vier Teststufen aus. Unit-Test, Integration- bzw. API-Test, Systemtest und Abnahmetest. Unit-Tests haben die niedrigsten Wartungs- und Durchführungskosten. Auch die Kosten für die Behebung der Fehler, die in den niedrigen Teststufen entdeckt werden, sind gering. Aus diesem Grund möchte man möglichst viel in den niedrigen Teststufen testen. Denn Abnahmetests oder E2E-Tests sind mit hohen Kosten verbunden.
Wie sieht die typische Testpyramide für BITV Tests aus?
Die Mehrheit der Tests erfolgt im Rahmen von kostspieligen und aufwändigen E2E- bzw. Abnahmetests. Hier besteht ein signifikantes Optimierungspotenzial, das durch die Automation und Agilisierung der Barrierefreiheitstestprozesse gehoben werden kann.
Welche Automationspotenziale existieren bei BITV Tests?
Die Automationspotenziale existieren bei Barrierefreiheitstests entlang der gesamten Wertschöpfungskette. Im Rahmen der Unittests sollte am besten eine organisationsweite Code-Richtlinie etabliert werden, die die Aspekte der Barrierefreiheit berücksichtigt. Diese Richtlinie soll Tools und Bibliotheken vorschreiben, die für die Entwicklung von barrierefreier Software innerhalb der Organisation zugelassen sind sowie die Standards, an die sich die Mitarbeitenden bei der Code-Erstellung halten sollen. Die Operationalisierung davon kann ein Profil in Sonar Cube, Axe Linting Tool oder einem vergleichbaren Tool erfolgen. Während der Entwicklung wird dann automatisch die Einhaltung der Code-Richtlinie bei jeder Änderung geprüft.
API-Level: Obwohl die BITV eine Anbindung an die GUI erfordert, können einige Validierungen auch ohne visuellen Hintergrund entstehen. So kann die Validität der erzeugten HTML-Codes, die Anwesenheit bestimmter Tags wie Alt-Text oder ARIA-Labels verifiziert werden. Insbesondere die BITV-konforme Darstellung von tabellarischen Inhalten stellt eine große Herausforderung dar.
Mit Hilfe von regelbasierten Tests auf API-Ebene lassen sich aber viele Zugänglichkeitsprobleme mit Tabellen frühzeitig identifizieren. Ein weiterer Vorteil ist die Schnelligkeit bei der Testdurchführung und Analyse der Testergebnisse. Im Idealfall können die fehlgeschlagenen Validierungen direkt in das Defektmanagement der Software übernommen werden.
GUI-Level: Ein Nachteil von GUI-basierten Tests ist, dass die Testung der GUI oft erst nur mit einem funktionierenden Backend möglich ist. Deswegen ist die Erstellung von GUI Mock-Ups sinnvoll. Dadurch wird die Front-end- und Back-end Entwicklung voneinander entkoppelt und ein höherer Parallelisierungsgrad erreicht.
Ein Teil der Barrierefreiheit ist auch die Kompatibilität mit diversen Browsern und Endgeräten. Plattformen wie Browserstack oder LambdaTest bieten hier skalierbare Lösungen für die Durchführung eines Kompatibilitätstests.
Auch für die Evaluierung der GUI basierten Tests gibt es automatisierte Lösungen. So kann man auf Basis von künstlicher Intelligenz mit Tools wie Percy Visual AI oder Axe DevTools, Änderungen in der Benutzeroberfläche zwischen der jeweiligen Code Version im Rahmen von Nightly Builds automatisch ermitteln und frühzeitig erkennen, wenn z.B. durch die Änderungen in der Benutzeroberfläche Steuerelemente überlappen oder die Kontraste zwischen den Elemente nicht BITV-konform sind.
Je höher wir in der Testpyramide aufsteigen, desto aufwändiger ist die Erstellung und Pflege der Automation. Aber selbst an der Systemtest- oder E2E-Testebene ist eine Teilautomation sinnvoll, z.B. mit Hilfe von assistiven Technologie wie Google Lighthouse oder Axe Auditor.
Ausblicke
Derzeit können mit den genannten Tools etwa 50-60 % der WCAG (Web Content Accessibility Guidelines)-Kriterien automatisch abgedeckt werden. Es ist nicht damit zu rechnen, dass in der Zukunft eine vollständige Automation der WCAG-Tests möglich sein wird. Bis 2030 könnten aber etwa 80 % der WCAG-Tests abgedeckt werden. Dabei helfen die aktuellen Entwicklungen im Bereich Spracherkennung und die rasant steigende Entwicklung von Large Language Models und KI.
Fazit
Barrierefreiheit stellt nicht nur eine gesetzliche Verpflichtung dar, deshalb sind effiziente Lösungen gefragt. Die herkömmlichen Barrieren bei der Implementierung von Barrierefreiheit in agilen Entwicklungsprozessen sind nicht länger akzeptabel. Die Verzögerungen durch manuelle BITV-Tests, die oft erst in späten Projektphasen durchgeführt werden, führen zu erheblichen Kosten und Risiken.
Die Etablierung der Testpyramide für Barrierefreiheit verspricht große Optimierungspotenziale. Von Unittests über API-Level-Tests bis hin zu GUI- basierten Tests können Tools und Richtlinien eingesetzt werden, um die Barrierefreiheit frühzeitig und kontinuierlich zu prüfen. Der Einsatz von Mock-Ups, regelbasierten Tests auf API-Ebene und automatisierten Kompatibilitätstests kann enorm helfen.
Die Brücke zwischen der Verpflichtung zur Barrierefreiheit und den Vorteilen für Unternehmen liegt in der intelligenten Nutzung von Automatisierungstechnologien. Ein barrierefreier Auftritt ist nicht nur ethisch geboten, sondern auch ein Schlüssel zur erfolgreichen und zeitnahen Umsetzung agiler Projekte. Es ist an der Zeit, nicht nur fast fertig zu werden, sondern wirklich fertig und barrierefrei zu sein und damit die Zukunft der digitalen Inklusion aktiv mitzugestalten.
Über den Autor:
Jakub Kratochvil hat über 10 Jahre Erfahrung in diversen Rollen im Rahmen der Qualitätssicherung. Seit 2023 ist er als Test Architekt bei Capgemini für innovative Ansätze in Testmanagement und Testautomation verantwortlich. Gemäß seines Mottos: “Klasse, statt Masse” berät er Kunden rund um das Thema Qualitätsicherung. In seiner Freizeit widmet sich der Diplom-Informatiker feiner Schokolade und Rum.
