reading book

Barrierefreiheit im agilen Umfeld

Barrierefreiheit im agilen Umfeld: von fast fertig zu wirklich fertig!

Oft habe ich meine Kollegen in der Entwicklungsabteilung gefragt, wie weit sie mit den Entwicklungsarbeiten fortgeschritten sind. Die häufigste Antwort lautete dabei: “Wir sind fast fertig!“ In den letzten Jahren vermehrt lautet diese Antwort: „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. Der Screenreader liest nicht korrekt vor, die Seite kann in bestimmten Auflösungen nicht korrekt abgebildet werden und die Tastaturbedienung funktioniert an einigen Seiten nicht oder die Tabsequenzen sind nicht intuitiv.

In dem nächsten Sprint wird dann fleißig entwickelt, dann muss der Test wiederholt werden, die Anzahl der Findings wird dabei zwar niedriger – oft ist aber ein dritter oder sogar vierter Anlauf notwendig, bis der erwünschte Testat erreicht werden kann. Erschwerend kommt dazu noch, dass die Dauer der Feedbackschleife bei Barrierefreiheitstest sehr lang ist. Häufig muss ein separater externer Dienstleister beauftragt werden, der Test muss in bestimmten Umgebungen oder gar 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. Mit dem Barrierefreiheitsstärkungsgesetz aus dem Jahre 2022 erweitert die Pflichten auf Telekommunikationsdienste, Bankdienstleistung sowie Personenbeförderungsdienste und Onlinehandel. Nun, Barrierefreiheit soll nicht nur als Erfüllung einer Pflicht verstanden werden. Viel mehr besteht hier eine Chance neue Kunden zu akquirieren und das Image der Organisation zu positionieren.

In Deutschland leben aktuell über 7,5 Millionen Personen mit einer Behinderung, die teilweise aus dem Angebot der Organisation ausgeschlossen werden. Ein Attraktiver und barrierefreier Auftritt der Firma prägt ebenfalls ein inklusives Image der Organisation und trägt zu höherer Erfüllung von Corporate Social Responsibility Kriterien bei.

 

BITV in der Alten Welt

In dem klassischen sequenziellen Entwicklungszyklus nach V-Modell XT ist die Überprüfung der Barrierefreiheit der Anwendung typischerweise Teil des Abnahmetests. Diese stellt die letzte Phase in dem Entwicklungszyklus dar und findet kurz vor der Inbetriebnahme statt.

Die Behebung der Fehler in dieser Phase ist äußerst aufwendig und kostenintensiv. Es ist ähnlich so, wenn ein Fehler in der Entwurfsphase bei dem Bauen eines Hauses entdeckt wird, reichen oft nur ein paar kleine Änderung in der Projektdokumentation und der Bau geht problemlos weiter. Wird aber erst wenn der Innenausbau fast fertig ist, festgestellt, dass die gesamten Leitungen im Bad um 10 cm nach rechts verlegt werden müssen, dann fallen beträchtliche Mehrkosten an und der Abnahmetermin wird um mehrere Monate nach hinten verlegt.

 

Manuelle BITV in der Agile Welt

Dagegen sieht die agile Entwicklung vor, dass nach jedem Sprint ein Releasekandidat produziert wird. Die Sprints erfolgen in 2–4-wöchigen Takt. Nun haben wir festgestellt, dass alleine ein manueller BITV Testlauf oft 2 Wochen in Anspruch nimmt. Und oft sind mehrere Testläufe erforderlich. Was passiert? Ohne Automation wird oft darauf verzichtet, dass Barrierefreiheit ein Teil der notwendigen Tests im Sprint ist. Wenn ein großes Release bevorsteht, dann wird das Produkt als fast fertig an die Abteilung für Barrierefreiheit ausgeliefert und die Geschichte von dem Exposé des Artikels wird deckungsgleich vorgesetzt.

Letztendlich wird der Product Owner oft mit der Wahl konfrontiert entweder ein nicht BITV- konformen System produktiv zu setzen und die damit verbunden Risiken oder Strafen zu riskieren oder noch weitere Projektverzögerungen in Kauf zu nehmen. Dabei sollte eigentlich die Reduzierung der Markteinführungszeiten der Kernvorteil der agilen Entwicklung sein.

Warum wird BITV oft zu einem Flaschenhals in Projekten?

Der Grundsatz des frühen Tests ist in der IT-Branche für funktionale Tests weit bekannt und praktiziert. Am einfachsten lässt sich dieser mit der in Abbildung 1 dargestellten Testpyramide darstellen. Nach ISTQB geht man von vier Teststufen aus. Unit Test, Integration bzw. API Test, Systemtest und Abnahmetest. Die Tests in den Unittests haben die niedrigsten Wartung und Durchführungskosten. Auch die Kosten für die Behebung der Fehler, die in den niedrigen Teststufen entdeckt werden, sind niedrig. Aus diesem Grund möchte man möglichst viel in den niedrigen Teststufen testen. Hingegen Abnahme Tests oder E2E-Tests sind mit hohen Kosten verbunden und daher soll Ihr Anteil möglichst niedrig bleiben.

Wie sieht hingegen die typische Testpyramide für BITV Tests aus?

Die Mehrheit der Tests erfolgt im Rahmen von kostspieligen und aufwendigen E2E bzw. Abnahmetests. Hier besteht ein signifikantes Optimierungspotenzial, der durch die Automation und Agilisierung der Barrierefreiheitstestprozesse gehoben werden kann.

Welche Automationspotenziale existieren bei BITV Tests?

Die Automationspotenziale existieren bei der Barrierefreiheitstest entlang der gesamten Wertschöpfungskette.

Im Rahmen der Unittests ist es essenziel ein Projekt, oder noch besser organisationsweite Code Richtlinie, zu etablieren, 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, sowie die Standards an die sich die Mitarbeitenden bei der Code Erstellen halten sollen. Die Richtlinie kann dann als ein Profil in Sonar Cube, Axe Linting Tool oder einem vergleichbaren Linting Tool operationalisiert werden. Während der Entwicklung wird dann automatisch die Einhaltung der Code Richtlinie bei jeder Code Änderung geprüft.

API-Level: Wobei die Mehrheit der BITV eine Anbindung an die GUI erfordert, können einige Validierungen auch ohne visuellen Hintergrund. 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 in vielen eine große Herausforderung dar und genau mit Hilfe von regelbasierten Tests auf API-Ebene lassen sich viele Zugänglichkeitsproblemen mit Tabellen frühzeitig identifizieren. Ein weiterer Vorteil von diesen Tests ist die Schnelligkeit bei der Testdurchführung und Analyse der Testergebnisse. Im Idealfall können die fehlgeschlagenen Validierungen direkt in das Defektmanagement Software übernommen werden.

GUI-Level: Ein Nachteil von GUI-basierten Tests ist, dass die Testung der GUI oft erst nur mit einer funktionierende Backend möglich ist. Um diesen Test frühzeitig durchführen zu können, ist die Erstellung von GUI Mock-Ups sinnvoll. Dadurch kann die Front-end und Back-end Entwicklung voneinander entkoppelt und höhere Parallelisierungsgrad erreicht werden.

Barrierefreiheitstests profitieren davon besonders stark, da diese teilweise nur über die Benutzerfläche evaluiert werden können.

Ein Teil der Barrierefreiheit ist auch die Kompatibilität mit diversen Browsern und mobilen Endgeräten. Plattformen wie Browserstack oder Lambdatest bieten hier skalierbare Lösungen für die Durchführung von Kompatibilitätstest, die an die Bedürfnisse der Organisation zugeschnitten werden können.

Auch für die Evaluierung der GUI basierten Tests gibt es mittlerweile automatisierte Lösungen. So kann man auf Basis von künstlicher Intelligenz mit Tools wie Percy Visual AI oder Axe DevTools, die Änderungen in der Benutzeroberfläche zwischen der jeweiligen Code Version im Rahmen von Nightly Builds automatisch ermitteln und frühzeitig erkennen, wenn zum Beispiel durch die Änderungen in der Benutzeroberfläche Steuerelemente überlappen oder die Kontraste zwischen den Elemente nicht BITV-konform sind.

Je höher in der Testpyramide wir aufsteigen, desto aufwendiger ist die Erstellung und Pflege der Automation. Aber selbst an der Systemtest- oder E2E-Testebene ist eine Teilautomation sinnvoll. Mit Hilfe von assistiven Technologie wie Google Lighthouse oder Axe Auditor werden dem Tester Tipps und Hinweise während der Durchführung der Tests gegeben, dies bewirkt eine weitere Beschleunigung der Barrierefreiheitstest. Aus fast fertig wird somit viel schneller wirklich fertig.

 

Ausblicke

Derzeit können mit den genannten Tools etwa 50-60% der WCAG-Kriterien automatisch abgedeckt werden. Es ist auch nicht damit zu rechnen, dass in der Zukunft eine vollständige Automation der WCAG-Tests möglich sein wird. Allerdings ist es zu erwarten, dass bis 2030 etwa 80% der WCAG-Tests abgedeckt werden können.

So ist es derzeit zum Beispiel in der Regel noch nicht wirtschaftlich automatisierte Test der Integration mit einem Screenreader oder mit einer Sprachbedienungssoftware durchzuführen. Die aktuellen Entwicklungen im Bereich Spracherkennung und die rasant steigende Entwicklung von Large Language Models und Künstlicher Intelligenz lässt vermuten, dass auch diese Funktionalität in Zukunft automatisch testbar sein wird.

 

Fazit

In der heutigen digitalen Ära, in der Barrierefreiheit nicht nur eine gesetzliche Verpflichtung, sondern auch eine Möglichkeit zur Kundenbindung und Imageverbesserung darstellt, sind effiziente Lösungen gefragt. Die herkömmlichen Barrieren bei der Implementierung von Barrierefreiheit in agile Entwicklungsprozesse 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 zu heben. 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. Durch den Einsatz von Mock-Ups, Regelbasierten Tests auf API-Ebene und automatisierten Kompatibilitätstests kann nicht nur die Effizienz gesteigert, sondern auch die Markteinführungszeiten verkürzt werden.

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.

 

jakub
Jakub Kratochvil
Senior Solution Architect
+49 (0)151 5277 7932