Barrierefreiheit in agilen Projekten

Bezüglich der konkreten Anforderungen an die Barrierefreiheit rekurriert die BITV 2.0 auf den Europäischen Standard EN 301 549. Dieser geht wiederum auf den internationalen Standard WCAG - Web Content Accessibility Guidelines – zurück, welcher von der Web Accessibility Initiative (WAI) des World Wide Web Consortiums (W3C) als ISO-Standard veröffentlicht und gepflegt wird (ISO 40500:2012). Die WCAG sieht die Umsetzung der Barrierefreiheit in drei Güteklassen vor: von A bis AAA. Die BITV 2.0 greift somit die Anforderungen der WCAG auf und differenziert diese entsprechend des jeweiligen IT-Angebots. In der Gesamtheit ergeben sich aus der WCAG eine Fülle querschnittlicher Anforderungen, welche je nach spezifischer Ausprägung des IT-Projekts Anwendung finden. In unserem aktuellen Projekt sind über 150 zu erfüllende Anforderungen einschlägig. Diese umfassen u. a. das Vorhandensein einer Erklärung zur Barrierefreiheit, die Bereitstellung ausgewählter Inhalte in Gebärdensprache und leichter Sprache, die Bedienbarkeit mit Maus und Tastatur, die Struktur der Seiteninhalte, Kontrastverhältnisse, die Einbindung von Audio- und Videoinhalten, die Gestaltung von authentifizierten Sitzungen, zeitliche Begrenzungen, Nutzereingaben sowie diverse weitere Aspekte. Eine erste pragmatische und besser handhabbare Zusammenfassung der Vorgaben erhält man durch das Lesen der Prüfschritte des sogenannten BITV-Tests. Dieses Testverfahren, welches zur Überprüfung des Reifegrads der Barrierefreiheit eingesetzt wird, ermöglicht durch Prüffragen und den inhärenten Praxisbezug einen niedrigschwelligen Zugang zu den komplexen und vielschichtigen Anforderungen. Zudem erweist sich der konsistente Aufbau für Einsteiger als leichter durchdringbar, im Vergleich zu den teils verschachtelten einschlägigen Normen und Standards. Erfüllt das eigene IT-Angebot die dort beschriebenen Kriterien, so kann man sich zumindest hinsichtlich der Bereiche, für die die BITV 2.0 kein Höchstmaß an Barrierefreiheit fordert, in recht großer Sicherheit wägen. Natürlich ersetzt dieser Test keine umfassende, möglichst entwicklungsbegleitend durchgeführten, Barrierefreiheitstests geschulter Barrierefreiheitstester, doch er liefert eine erste Indikation und kann somit als Gradmesser für die Reife der IT-Lösung eingesetzt werden.

Die Sicherstellung dieser Vorgaben in einem klassischen Wasserfallmodell ist vergleichsweise einfach zu realisieren. Sobald eine genaue Systemspezifikation konzipiert wurde, gilt es einen auf Barrierefreiheit spezialisierten Experten zu beauftragen. Dieser arbeitet die Spezifikation durch und optimiert sie strukturiert hinsichtlich der Barrierefreiheit. Deutlich kniffliger wird die Gewährleistung der Barrierefreiheit im Kontext von agilen Vorgehensmodellen. Insbesondere wenn diese zusätzlich in ein skaliertes Framework eingebettet sind, bspw. nach SAFe. Diese gewinnen jüngst auch im öffentlichen Sektor aufgrund der nicht von der Hand zu weisenden Vorteile zunehmend an Popularität.

Doch wie kann die Einhaltung von ca. 150 Vorgaben in einem Projekt sichergestellt werden, welches von dezentralen Entscheidungen lebt und in welchem die Verantwortung für einzelne Teilaspekte über mehrere Dienstleister, Product Owner, Software Entwickler, unterstützende UX-Experten und Fachautoren verteilt ist?

Die wohl schlechteste Antwort ist das Ignorieren der Thematik bis kurz vor oder nach dem Roll-out. Die dann erforderlichen Anpassungen führen meist zu Verzug und erheblichen Mehrkosten. Dieses offensichtliche Risiko sollte nicht sehenden Auges ignoriert, sondern frühzeitig und adäquat adressiert werden. Doch welche Lösungswege werden gegenwärtig beschritten? Oftmals werden in Projekten Schulungen für die beauftragten Entwickler durchgeführt, die meist auf eher wenig Begeisterung stoßen, da sie sich mit einer allgemeinen Darstellung der Erfordernisse der Barrierefreiheit begnügen. Zudem werden in den Projekten in regelmäßigen Zyklen Barrierefreiheitstests durchgeführt, um etwaige Probleme beheben zu können. Eindeutiger Nachteil dieser Vorgehensweise ist die mangelnde projektspezifische

Befassung mit der Barrierefreiheit. Der Transfer des gewonnen Wissens auf die Herausforderungen der Entwicklung obliegt den Entwicklern, welche häufig mit offene diesen Fragen allein gelassen werden. Die Folge ist, dass Anforderungen der Barrierefreiheit häufig nicht unmittelbar entwicklungsseitig umgesetzt und Fehler erst im Nachhinein entdeckt werden. Das hieraus resultierende Erfordernis häufiger Anpassung bereits entwickelter Funktionalitäten sorgt, besondere am Anfang von Entwicklungsprojekten, für Frustration aller Beteiligten.

In Abgrenzung zur gegenwärtigen Praxis haben wir als Cassini ein sechsstufiges Konzept zur entwicklungsbegleitenden Sicherstellung der Barrierefreiheit in agilen Projekten entwickelt. Kern dieses Konzeptes ist die Institutionalisierung der folgenden Maßnahmen:

1. Prägnante, zielgruppen- und projektspezifische Guidelines (für Product Owner, Entwicklung, die Fachseite etc.)
2. Entwicklungsbegleitende Tests durch geschulte BITV-Tester
3. Einführung einer übergreifenden Rolle zur Gewährleistung der Barrierefreiheit
4. Fortlaufende präemptive Prüfungen konzeptioneller Artefakten (z. B. User Stories und
   UX-Designs) seitens des Product Owners
5. Formulierung dezidierter User Stories zur Gewährleistung der Barrierefreiheit
6. Projektspezifische Barrierefreiheits-Schulungen und Barrierefreiheits-Retrospektiven
   zum gemeinschaftlichen und nachhaltigen Aufbau projektspezifischer Expertise

Beispiel für den Guideline-Einsatz: Gibt ein Product Owner, gemäß seiner Guideline, bereits Alternativtexte für Bilder in der User Story für die Umsetzung an, so muss dies nicht mehr in der Guideline für Softwareentwickler berücksichtigt werden. Dieses Schneiden der Zuständigkeiten für einzelne Anforderungen sorgt für Klarheit und entlastet in diesem Fall den Entwickler.

Betrachtung der Barrierefreiheits-Schulungen und -Retrospektiven: Die allgemeine und meist ernüchternde Schulung für Softwareentwickler werden durch projektspezifische Barrierefreiheits-Schulungen und -Retrospektiven ersetzt. In diesen werden auf Basis von vergleichbaren Projekten und vergangenen Entwicklungsergebnissen Unzulänglichkeiten und Fehler diskutiert und erläutert. Die gewonnen Erkenntnisse fließen zurück in die Überarbeitung der Guidelines, sodass diese als projektspezifische Kompendien aufwachsen. Zudem wird durch den Diskurs die kontinuierlichen Wissensvermittlung der Projektbeteiligten sichergestellt.

Unser sechsstufiges Konzept zur entwicklungsbegleitenden Sicherstellung der Barrierefreiheit in agilen Projekten hat sich als zielführend und wirksam herausgestellt, da hierdurch das

Thema nah an den Entwicklungsprozess geholt wird, klare Verantwortlichkeiten definiert werden und projektspezifische Unterstützungsangebote bereitgestellt werden. Ganz im Sinne einer agilen Vorgehensweise werden wir unser Konzept stetig auf den Prüfstand stellen, praxisbezogen optimieren und fortentwickeln.

Das Thema Barrierefreiheit ist für die meisten nicht ansatzweise so interessant wie neue Frontend-Technologien, agile Methoden, Testautomatisierung oder Continuous Integration – es hat schlichtweg einen faden Beigeschmack. Das Erfordernis der Gewährleistung der Barrierefreiheit führt jedoch zu hochspannenden Fragen:

• Wie lassen sich die unzähligen querschnittlichen Anforderungen in agilen Vorgehensmodellen einsteuern?
• Welchen Rahmen benötigt ein Team, um dezentral Wissen und Awareness für dieses Thema aufzubauen und es in die Entwicklung einfließen zu lassen?
• Was bedeutet die zusätzliche Belastung aller Rollen mit einem nicht-originären Thema für die Geschwindigkeit des Entwicklungsprozesses?

Wir unterstützen Sie gerne dabei Ihre projektspezifische und bedarfsorientierte Antwort auf diese Fragen zu finden, um Ihr Produkt besser und Ihr Team erfolgreich zu machen.