In vielen Unternehmen werden heute Methoden der agilen Softwareentwicklung eingesetzt. Egal, ob es sich dabei um Scrum, Kanban oder einen anderen agilen Ansatz handelt: Das Ziel ist es immer bürokratische Prozesse im Projekt abzubauen und die Selbstorganisation von Teams zu fördern. In einigen Unternehmen sind nur Teile des Prozesses agil; aber selbst in umfassend agil arbeitenden Unternehmen ist meiner Erfahrung nach die Barrierefreiheit selten ein integraler Bestandteil des agilen Prozesses.
Oft wird das Testen auf Barrierefreiheit als nachträgliche Anforderung ans Ende des Projektes gelegt; entsprechend passiert auch die Umsetzung der Anforderungen an die Barrierefreiheit nachgelagert – und konterkariert damit die Prinzipien des agilen Entwicklungsprozesses. Was man mit der Agilität erreichen wollte – die Selbstbefähigung von Teams zur vollständigen Umsetzung von funktionierender Software – wird so nachträglich durch die Accessibility Experten in Frage gestellt – und führt entsprechend zu Frustration bei den Beteiligten und mangelhafter Umsetzungsqualität.
Nachgelagerte Korrekturprozesse sind meist aufwendiger und damit kostenintensiver. Ein Fehler in der Tastatursteuerung könnte im ersten Sprint innerhalb eines Tages gelöst werden. Wird der Fehler erst in einer nachgelagerten Prüfung entdeckt, bauen vielleicht schon weitere Teile der Applikation auf der problematischen Komponente auf, und die Korrektur kostet das Entwicklerteam entsprechend mehrere Tage (und viele Nerven). Hinzu kommt der Zeitaufwand für das Testen und Dokumentieren sowie die zusätzliche Kommunikation.
Aber selbst wenn die Accessibility schon im laufenden Projekt berücksichtigt werden soll und zum Beispiel durch Tester entsprechende Aufgaben zur Verbesserung der Applikation angelegt werden, passiert es schnell, dass Accessibility Tasks im Backlog gegen neue Features oder Bugfixes verlieren.
Was sind die Gründe für diese problematische Situation und wie kann man den Prozess verbessern?
Barrierefreiheit als Teil der Firmenkultur
Im agilen Prozess wird (wenn es gut läuft) immer zuerst die Aufgabe erledigt werden, die als am wertvollsten für das Projekt bewertet wird. Ein Grund, weshalb die Barrierefreiheit zu kurz kommt, liegt also offenbar in einem mangelnden Bewusstsein für den Wert einer barrierefreien Umsetzung.
Zunächst muss also ein Bewusstsein für den Wert und Nutzen der Barrierefreiheit bei allen Projektbeteiligten geschaffen werden, das über das Erfüllen rechtlicher Anforderungen hinausgeht.
Wir beobachten oft, dass in Teilen des Teams bereits tiefergehendes Wissen über Barrierefreiheit vorhanden ist und einfach brach liegt. Zugunsten anderer Ziele und mit Hinweis auf den Zeitdruck wird die unmittelbare korrekte und barrierefreie Umsetzung unterlassen.
Die Aufgabe des Managements ist es daher, dem Team klar zu machen, dass die Barrierefreiheit nicht von wichtigeren Aufgaben abhält; vielmehr hilft die Berücksichtigung der Barrierefreiheit, (mittelfristig) Geld zu sparen und die Qualität des Produkts zu verbessern.
Damit die Barrierefreiheit aber nicht nur eine Anforderung von außen ist, sondern integraler Bestandteil des (selbstorganisierten) Entwicklungsprozesses wird, müssen häufig erst zahlreiche Vorurteile gegenüber barrierefreien Produkten ausgeräumt werden. Barrierefreie Gestaltung bedeutet nicht, dass Produkte und Interfaces am Ende klobig und altbacken aussehen müssen wie manche Senioren-Handys. Das iPhone zum Beispiel setzt regelmäßig neue Maßstäbe sowohl beim Thema User Experience als bei der Barrierefreiheit.
Wissen in die Teams bringen und vermehren
Nachdem das Bewusstsein über den Wert der Barrierefreiheit für das Produkt geschaffen wurde, muss ein breit aufgestelltes Wissen, wie man Barrierefreiheit im Team umsetzt, aufgebaut werden. Personen im Team, die bereits Wissen besitzen, können dabei als Multiplikatoren dienen. Eine effektive Möglichkeit ist auch die Organisation von Workshops und Schulungen für jede Gruppe (UX Experte, Programmierer usw.).
Die Aufgabe des Accessibility Experten wandelt sich in diesem Zusammenhang vom Accessibility Cop zum Accessibility Consultant. Anstatt ausschließlich am Ende im stillen Kämmerchen seine Tests zu absolvieren und lange Testberichte zu schreiben, arbeitet er während des Projektes aktiv und konstruktiv mit, sucht gemeinsam nach Lösungen und ist Teil des Teams; er hilft bei Verständnisfragen und gibt Hinweise, auf was zu achten ist oder wo genauere Informationen zu finden sind.
User Stories
Da in agilen Projekten Spezifikationen meist in Form von User Stories erfolgen, ist es wichtig, die Anforderungen der Barrierefreiheit direkt in den User Stories zu berücksichtigen. Auf diese Weise sind sie bei allen Prozessschritten von der Sprintplanung bis hin zur Abnahme präsent.
Eine Möglichkeit besteht darin, User Stories um die Anforderungen der Barrierefreiheit in Form von Akzeptanzkriterien anzureichern. Dabei sollten immer die zum Kontext der Aufgabe passenden Anforderungen der Barrierefreiheit als Akzeptanzkriterien eingetragen werden. So ist es wenig hilfreich für das Team, wenn in jeder User Story nur das sehr allgemeine Akzeptanzkriterium „barrierefrei nach WCAG“ ergänzt wird.
Da für die Ausformulierung der Akzeptanzkriterien zum größten Teil das Team selbst derverantwortlich ist, kann es insbesondere in Teams ohne expliziten Accessibility Experten passieren, dass einzelne Aspekte der Barrierefreiheit vergessen werden. Diese Lücken werden durch durch den weiterhin durchgeführten Accessibility Test durch einen Experten abgefangen – im Idealfall möglichst früh im Prozess. Mit steigender Erfahrung des Teams ist die explizite Erwähnung bestimmter Basics nicht mehr nötig. Man konzentriert sich dann auf die spezifischen Herausforderungen bei einer Aufgabe (z.B. Tastatursteuerung von Drag-and-Drop Interaktionen).
User Story Beispiel
Als Nutzer möchte ich meine Rechnung zusätzlich drucken können
Akzeptanzkriterien:
- Druck-Funktion (Button) muss tastaturbedienbar sein und ausreichende Farbkontraste aufweisen
- Das Drucklayout muss ausreichende Farbkontraste aufweisen
Testen, testen, testen
Frühzeitiges und häufiges Testen ist ein wesentlicher Bestandteil eines agilen Entwicklungsprozesses. Nach Möglichkeit sollte dabei bereits während der Umsetzung getestet werden. Designer prüfen die Farbkontraste bereits im Grafikprogramm, Entwickler kontrollieren die Tastatursteuerung kontinuierlich, während sie die Komponente programmieren. Die Tests sollten dabei so nahtlos wie möglich in den Arbeitsalltag des Teams integriert werden. Wenn zum Testen immer erst eine virtuelle Maschine hochgefahren werden muss, weil das Tool nicht für das aktuelle Betriebssystem existiert, wird niemand die Tests durchführen.
Was immer automatisiert getestet werden kann, sollte automatisiert getestet werden. Ein häufiger Fehler, der gleichzeitig sehr gut automatisiert getestet werden kann, sind fehlende Bezeichnen (labels) für Eingabefelder (inputs). Wenn bereits automatisierte Tests (zum Beispiel im Rahmen eines Continous Integration Prozesses) laufen, sollten Tests zur Barrierefreiheit entsprechend ergänzt werden.
Ein Kernpunkt der agilen Methode ist es, nach jeder Iteration funktionierende Software auszuliefern. Dazu gehört die Barrierefreiheit. Entsprechend sollte neben den automatisierten Tests während der Entwicklung auch ein Accessibility Experten-Test bzw. Audit zu einem Sprint gehören. Was für das gesamte Produkt gilt, gilt dabei auch auf der Ebene des Sprints: Findet das Experten-Review erst nach Abschluss des Sprints statt, ist keine Zeit mehr, etwaige Probleme im Rahmen des Sprints zu beheben.
Made with love and accessibility in mind
Viele Teams beschreiben Barrierefreiheit als lästig, innovationsfeindlich und wahnsinnig bürokratisch. Für mich ist ein Grund für diese negativen Assoziationen und Erfahrungen die mangelhafte organisatorische Integration der Barrierefreiheit in den Projektverlauf und die oft problematische Kommunikation von Accessibility Experten gegenüber dem Team. Dabei passen die Prinzipien der agilen Softwareentwicklung, die den Menschen und die menschliche Interaktion ins Zentrum stellen, eigentlich gut zu den Prinzipien der Barrierefreiheit.
Durch die stärkere Befähigung des Teams, den Wert der Barrierefreiheit zu sehen und die damit zusammenhängenden Anforderungen selbstständig zu erkennen, sowie durch die frühzeitige konstruktive Mitarbeit des Accessibility Experten während der Entwicklung, kann ein agiler Entwicklungsprozesses dazu beitragen, Reibungsverluste im Projekt zu reduzieren und insgesamt die Qualität zu steigern. Auch für mich als Accessibility Experte stellt diese Umstellung der Arbeitsweise eine spannende Herausforderung dar.
Geschäftsführer der mindscreen GmbH, Accessibility-Experte und Web Developer
Stefan Farnetani berät und unterstützt Unternehmen bei der Umsetzung barrierefreier Websites und Web-Anwendungen.
Zusätzlich engagiert er sich mit Vorträgen und in Arbeitsgruppen für das Thema Barrierefreiheit.
Aktuell ist er u.a. Leiter des Arbeitskreis Barrierefreiheit der German UPA e.V., dem Berufsverband der Deutschen Usability und User Experience Professionals.