Barrieren der digitalen Barrierefreiheit – Zeitdruck

In dieser Blogreihe widmen wir uns den Gründen, warum Barrierefreiheit immer noch eine Herausforderung für vielen Webentwicklungsprojekte darstellt. In diesem Artikel nehmen wir den Zeitdruck beziehungsweise Zeit als Engpass genauer unter die Lupe.

Zeit als Barriere in der Barrierefreiheit

Die moderne Webentwicklung steht trotz ihrer noch jungen Existenz bereits vor komplexen Herausforderungen. Wie fast alle Teilbereiche der Informatik trifft hier eine äußerst junge Disziplin auf eine nie da gewesene, weltweite Nachfrage. Die daraus resultierende Nutzergruppe ist beispiellos in ihrer Diversität. Während sich andere Disziplinen – etwa die Medizin – über Jahrtausende in überschaubaren Kontexten mit überschaubaren Nutzergruppen entwickeln konnten, wirkt die bisher vergangene „Reifephase“ in der Webentwicklung wie ein Wimpernschlag.

Dies darf jedoch nicht als Ausrede dienen, um nicht alles Notwendige und Mögliche zu tun, um die maximale Anzahl an willigen Rezipientinnen einzubeziehen. Besonders UX-Designerinnen und Webentwicklerinnen als Gestalter des Zugangs tragen eine enorm hohe Verantwortung. Bewusst oder unbewusst werden sie oft zu sogenannten Gatekeepern von Leistungen, Wissen oder grundsätzlich Informationen. Dieser Effekt ist, zumindest von Einzelpersonen in der Webentwicklung, selten beabsichtigt. Wir kennen kaum Webentwicklerinnen oder Designerinnen, die in jedem Projekt mehrere Design-Sprints darauf verwenden, ihre Arbeit schlechter auffindbar, unübersichtlicher oder gar verwirrender zu gestalten.

Der Zeitdruck

Einer der prägnantesten Engpässe – in der IT oft als „Flaschenhals“ bezeichnet – ist der Zeitdruck. Viele Lesende werden das nur allzu gut kennen. An irgendeiner, nun nicht mehr nachvollziehbaren Stelle in der Projektplanung, durch eine nicht mehr identifizierbare Einzelperson oder ein Komitee, wurde entschieden, dass ein Projekt eine bestimmte Dauer zu haben hat. Diese Entscheidung wird dann vom „Management-Silo“ ins „Entwicklungssilo“ ohne viel Federlesen weitergereicht. Nun steht das Entwicklungsteam unter Zugzwang, innerhalb dieser vorgegebenen Zeit zu liefern – und alles „Unnötige“ hintenanzustellen.

Oft betrifft das neben gutem Design und intensivem Testing auch das Thema Barrierefreiheit. Begriffe wie „stiefmütterlich behandelt“ fallen einem dazu ein – besonders, wenn ein DevOps-Hintergrund vorhanden ist. Barrierefreiheit, wie so viele Fokusthemen der kontinuierlichen Verbesserung, wird als Bonus betrachtet. Für den Bonus ist immer erst Zeit vorhanden, wenn die „wichtigen“ Dinge erledigt sind oder „der nächste Release durch ist“. Erfahrungsgemäß kommt dieser Zeitpunkt einmal im Jahr, aber da sind ganz unvorhersehbar alle Teammitglieder im Urlaub und es kann leider, leider nicht gehandelt werden.

Es ist nicht von der Hand zu weisen, dass manuelles Testen – insbesondere im Bereich Barrierefreiheit – Zeit und Fachwissen erfordert. Zunächst muss entschieden werden, welcher Regelkatalog zur Konkretisierung des oft schwammigen Begriffs „Barrierefreiheit“ herangezogen wird. Ist diese Entscheidung dann zumindest einmal getroffen und abgenickt, kann sich die Umsetzung erheblich ziehen, da in der Regel nicht genug Zeit dafür eingeplant wird. Es kann Jahre dauern, bis beispielsweise die über 70 Erfolgskriterien der WCAG 2.1. gelesen, verstanden, angewendet, kontinuierlich überprüft und idealerweise in automatisierte Tests überführt wurden. Die Zeit für manuelle Prüfungen oder Regressionstests ist da noch nicht einmal berücksichtigt!

Nicht zuletzt erfordert die Umsetzung all dieser Schritte ein gewisses Maß an Spezialwissen. Dieses muss zunächst geschult und im Projektalltag verankert werden. Wir gehen davon aus, dass es durchschnittlich 40 Stunden dauert, um einen einzelnen Webauftritt nachträglich an die WCAG anzupassen. Ist das eine exakte Zahl? Nein. Aber in unseren Augen ist es auch keine übertriebene. Diesen zeitlichen Aufwand sehen wir als eine Barriere der Barrierefreiheit, welchen es mit unserer Arbeit zu adressieren gilt.

Fazit

Wenn Barrierefreiheit erst nachträglich eingebaut werden soll, braucht es Zeit, Geduld und Spezialwissen. Zudem muss oftmals erst Überzeugungsarbeit geleistet werden, damit sich für dieses vermeintliche Bonus-Thema überhaupt Zeit genommen werden darf. Es muss geklärt werden, was genau gefordert ist – und dann, wie eine saubere Umsetzung im eigenen Kontext aussehen kann. Das bedeutet für die verantwortliche Fachkraft: Regelwerke lesen, Inhalte überarbeiten, Code anpassen, Tests durchführen – und das alles möglichst, ohne das bestehende Design zu zerschießen. Oft fehlt dafür schlicht die Motivation, Zeit und das Wissen. Und auch eine kompetente und motivierte Person wird zu oft durch den ewig herrschenden Zeitdruck ausgebremst. Der nicht mehr nachvollziehbare Projektplan steht über altruistischen Werten – und eine Barrierefreiheit, die nicht von Anfang an mitgedacht wurde, muss nun in mühsam zusammengekratzter Zeit nachgebessert werden.

Darin liegt eines der grundlegenden Probleme von Verbesserung: Jene, die nach ihr streben, stehen zu Beginn oft allein da – und werden mit mehr Arbeit „bestraft“. Im Fall der Barrierefreiheit gilt: Was man am Anfang aus Zeitdruck „vergessen“ hat, kostet die motivierten Teamkolleg*innen später sehr viel Mühe und Aufwand.

Accesstra soll ein Baustein sein, um diesen inakzeptablen Status quo anzugehen.

Geschrieben von Georgia König
Accesstra Instructor