publicplan GmbH

Barrierefreiheit ist kein Zusatz, der zum Ende eines Projektes „nachgerüstet“ oder getestet werden kann, obwohl genau das in der Praxis häufig der Fall ist. Diese Nachrüstungen sind enorm entwicklungsaufwendig und kostenintensiv. Das wird in Projekten häufig unterschätzt und wer gleich zu Beginn des Projektes auf Sparkurs geht, muss sich darauf gefasst machen, das Projektende nur sehr mühselig oder gar nicht erst zu erreichen ist.

Wie sollte die Projektvorgehensweise stattdessen gestaltet werden, um genau diese Probleme zu umgehen? Ich erkläre es am Beispiel eines agilen Projektes: Planung, Design, Entwicklung, Testing und Release.

Barrierefreiheit von Anfang an mitdenken

(Planungsphase)

Bereits in der Planung müssen Anforderungen zur Barrierefreiheit berücksichtigt werden, damit Produkte oder Dienstleistungen entsprechend der gesetzlich verpflichtenden Vorgaben (BITV 2.0 und BGG) entwickelt und getestet werden können. Allerdings scheitern Projekte hier schon mit Aussagen wie: „Der Kunde gibt dafür kein Budget frei“, „Barrierefreiheit interessiert nicht“ oder auch schlichtweg die Angst vor fehlenden Know-how.

Lösung: Ein solides Know-how kann man sich aneignen, dies kann aber dauern. Es ist empfehlenswert, Barrierefreiheitsbeauftragte hinzuzuziehen oder mindestens eine Person aus dem Entwicklungsteam als Accessibility Champion zu ernennen. So lassen sich Mindestanforderungen im Rahmen der zu erhebenden Anforderungen zu definieren und Kunden davon zu überzeugen, dass die Aufnahme minimaler Grundanforderungen bereits in der Planungsphase auf lange Sicht deutlich mehr Geld spart als gegenteiliges Vorgehen. Das setzt natürlich gute und gezielte Beratung voraus.

Konkrete Mindestanforderungen definieren

Gehen wir davon aus, dass der Kunde XY aus der Verwaltung seine Website überarbeiten möchte. Kompetente Barrierefreiheitsbeauftragte würden an dieser Stelle die Aufnahme folgender Mindestanforderungen empfehlen:

1. ‍Semantik & sauberes HTML (WCAG 1.3.1, 4.1.1 & 4.1.2) ‍
2. Farbkontraste & visuelle Wahrnehmbarkeit (WCAG 1.4.3, 1.4.11) ‍
3. Tastaturbedienbarkeit (WCAG 2.1.1, 2.1.2, 2.4.7) ‍
4. Responsives Design & Reflow (WCAG 1.4.10, 1.4.4) ‍
5. Testing mit assistiven Technologien (mindestens NVDA)

Diese Mindestanforderungen werden in der Definition of Done (DoD) hinterlegt oder zumindest wird dort festgehalten, dass beispielsweise keine Story erledigt ist, solange die Barrierefreiheit nicht geprüft wurde.

Barrierefreies Design als Grundlage

(Designphase)

Eine gute und präzise Anforderungsgrundlage erleichtert dem UX/UI-Team die Arbeit an maßgeschneiderten Designs erheblich. Mit wiederverwendbaren, barrierefreien Komponentenbibliotheken können Designs effizient umgesetzt werden. Lieben wir doch!

Aber Achtung: Individuelle Anpassungen können neue Barrieren schaffen. Deshalb empfiehlt sich auch hier Barrierefreiheitsbeauftragte hinzuzuziehen, die gemeinsam mit dem UX/UI-Team Screens prüfen und mögliche Barrieren aus dem Weg räumen. Idealerweise wird das Know-how gezielt geschult, um Wissen nachhaltig im Team aufzubauen und zu halten.

Barrierefreiheit als Teil der Umsetzung

(Entwicklungsphase)

Auf Grundlage der zuvor beschriebenen Designphase kann es jetzt doch nur noch bergauf gehen, oder? Ja, leider nicht ganz.

Ganz wichtig in der Entwicklungsphase ist: Je präziser die Vorgänge zuvor strukturiert und dokumentiert (inkl. Screens), desto höher ist die Wahrscheinlichkeit, dass die gewünschte Komponente, zum Beispiel das Hauptmenü der Website, auch genauso umgesetzt wird, wie es das Design ursprünglich vorgesehen hat.

Das bedeutet konkret

Accessibility-Kriterien müssen explizit als Akzeptanzkriterien in den Tasks festgelegt werden, zum Beispiel:

1. Funktion (Hauptmenü der Website) erfüllt WCAG-Anforderungen (hier explizit die Erfolgskriterien der WCAG benennen)
2. Tastaturbedienbarkeit und Screenreader-Kompatibilität getestet
3. Farbkontraste geprüft
4. Responsives Layout geprüft

Übersetzt heißt das

Der Entwickler oder die Entwicklerin der jeweiligen Komponente ist für die Erfüllung dieser Akzeptanzkriterien verantwortlich. Ist dies nicht der Fall, gilt die Story oder der Task auch nicht als abgeschlossen. Hier sollte jedoch Rücksprache gehalten und geprüft werden, wo genau das Problem liegt.

Im Refinement innerhalb eines Sprints besteht die Möglichkeit, Rückfragen zu Anforderungen innerhalb von Tasks zu stellen. Hier kann entweder die verantwortliche Person aus dem UX/UI-Team teilnehmen oder der / die benannte Accessibility Champion aus dem Entwicklungsteam, um die Anforderungen an die gewünschte Komponente oder Funktionalität vorzustellen.

Die Entwicklerinnen und Entwickler kommen jedoch nicht darum herum, sich mit den Accessibility-Anforderungen auseinanderzusetzen und diese zu verstehen, d. h. eigenständig im WCAG-Katalog nachzulesen und anhand von Beispielen zu verstehen, warum bestimmte Kriterien wichtig sind und wie sie technisch umzusetzen sind. Je früher dies geschieht, desto effizienter laufen Entwicklungsprozesse ab und desto höher ist die Qualität der Endprodukte.

Barrierefreiheit realistisch testen

(Testingphase)

In den meisten Fällen testet der jeweilige Entwickler oder die Entwicklerin die eigene Komponente selbst, bevor sie zur Abnahme durch den Product Owner weitergereicht wird. Ich habe aber auch schon erlebt, dass die Rolle der Testerin oder des Testers in agilen Projekten eingeführt wurde, um das Testing auszulagern und dem Entwicklungsteam mehr Fokus auf den eigentlichen Entwicklungsprozess zu ermöglichen.

Wichtig ist, dass das Testing entlang der definierten Akzeptanzkriterien erfolgt: Tastatur, Screenreader, unterschiedliche Browser. 

Nur so kann die tatsächliche User Experience erlebt und Barrieren sichtbar werden, die selbst einigen Barrierefreiheitstools wie axe-core oder dem ARC Toolkit verborgen bleiben.

Barrierefreiheit ist kein Last-Minute-Thema

(Releasephase)

Dass Barrierefreiheit nicht nachgerüstet werden kann, sollte spätestens zu diesem Zeitpunkt klar sein. Die Praxis zeigt jedoch häufig, dass viele Projekte erst kurz vor dem Release ein Bewusstsein oder gar eine Notwendigkeit zur Berücksichtigung der Barrierefreiheit entwickeln. Entweder, weil das Produkt ohne die Erfüllung gesetzlicher Vorgaben vermutlich nicht lange genutzt werden darf oder weil gesetzliche Folgen wie Abmahnungen und Bußgelder drohen, was der Gesetzgeber in der öffentlichen Verwaltung meiner Meinung nach viel zu milde handhabt.

In dieser Projektphase bietet sich die Durchführung anerkannter Prüfverfahren wie etwa des BIK-BITV-Tests für Websites an, um den Grad der Barrierefreiheit zu überprüfen. Da solche Tests jedoch sehr kosten- und zeitintensiv sind, ist es ratsam, Barrierefreiheit nicht erst zum Release zu betrachten, sondern als festen Bestandteil des gesamten Projektprozesses zu verstehen.

Zu Beginn kann Barrierefreiheit überwältigend wirken, was vollkommen verständlich ist. Gerade deshalb sind kleine Schritte im Sinne minimaler Grundanforderungen wichtig und mit Unterstützung durch Barrierefreiheitsbeauftragte oder engagierte Projektmitglieder deutlich besser handhabbar.

Barrierefreiheit in Projekten wird dadurch nicht mehr unerreichbar, sondern systematisch, planbar und vor allem frühzeitig machbar.