Wenn man länger in der digitalen Barrierefreiheit arbeitet, kommt man sich wie ein Papagei vor. Das liegt daran, dass man immer wieder das Gleiche erzählen muss – manchmal sogar der gleichen Person.
Ich kenne ja beide Perspektiven: Einerseits war ich selbst lange Zeit freiberuflich Dienstleister, andererseits war ich auch für einige Kunden als Steuerung für digitale Barrierefreiheit zuständig. Seit fast vier Jahren arbeite ich für Agenturen wiederum als Dienstleister. Die Perspektiven und Herangehensweisen können sich unterscheiden, im Wesentlichen ist es aber relativ ähnlich.
Natürlich hat man als Dienstleister zunächst das Interesse, möglichst viele anrechenbare Stunden zu generieren. Aus meiner Sicht ist das aber nicht immer produktiv gedacht: Der Kunde hat immer die Wahl, seinen Dienstleister auszutauschen, wenn er den Eindruck hat, dass dieser nicht effizient arbeitet. Es ist also keine gute Idee, erstmal etwas zusammenzuwursteln, um sich dann irgendwann um die Barrierefreiheit zu kümmern.
Umgekehrt sollte der Kunde beachten, dass Barrierefreiheit richtig umzusetzen eher ein Marathon als ein Sprint ist. Wer den billigsten Anbieter nimmt, zahlt im Zweifelsfall hinterher doppelt.
Hier möchte ich die aus meiner Sicht wesentlichen Erfolgs-Faktoren zusammenfassen. Die Schritte werden hier bewusst nicht in eine bestimmte Reihenfolge gebracht.
Design/Konzeption
Einige Aspekte müssen bereits beim Design und der Konzeption eines Produktes bedacht werden: Das sind vor allem Farben, Kontraste und visuelle Indikatoren. Im Grunde sind es wenige Aspekte, die aber bei jedem Projekt, mit dem ich zu tun hatte vernachlässigt werden.
Auf der Kundenseite ist es sinnvoll, diese Aspekte bereits in das Corporate Design aufzunehmen. Wenn das nicht möglich oder gewünscht ist, muss man spezielle CD-Regeln für den digitalen Bereich definieren.
Von Dienstleister-Seite aus kann man mit Akzeptanz-Kriterien arbeiten. Diese Kriterien definieren die Mindest-Bedarfe an alle UI-Komponenten. Ein Beispiel: Ein Link muss 1. einen Kontrast von mindestens 4,5:1 oder 3:1 zum Hintergrund haben und zwar in jedem Stadium (besucht, nicht-besucht, fokussiert etc.
Auf Kundenseite macht es Sinn, hier möglichst eine eigene Komponenten-Bibliothek aufzubauen, wenn man zahlreiche digitale Produkte hat. Auch für den Dienstleister kann das sinnvoll sein, wobei das natürlich flexibler sein muss, weil es auf jeden Kunden angepasst werden muss, was etwa Farb-Schemata angeht.
Entwicklung
Auch für die Entwicklerinnen ist eine solche Bibliothek hilfreich. Viel hängt davon ab, ob man eine kleine Agentur ist. Kleine Agenturen haben ein begrenztes Set an Bibliotheken und CM-Systemen, auf welche sie spezialisiert sind. Dann ist es sinnvoll, die Bibliotheken so anzupassen, dass sie die Anforderungen der Barrierefreiheit erfüllen. Auf mittlere Sicht dürfte es aber fast einfacher sein, eigene wiederverwendbare Komponenten, die barrierefrei sind. Während Frameworks regelmäßige Updates brauchen, könnte man große Teile von HTML, CSS und JavaScript bis heute problemlos weiterverwenden.
Für große Dienstleister ist es aber unabdingbar, Regeln zur Verwendung von Bibliotheken einzuführen. Wenn eine Bibliothek immer ein bestimmtes Problem mit einer bestimmten Komponente produziert, sollte dies möglichst so gefixt werden, dass es nicht mehr auftritt. Natürlich wäre es am besten, dass Problem durch den Anbieter der Bibliothek fixen zu lassen, allerdings weiß ich nicht, wie komplex solche Prozesse sind.
Automatisierung und Standardisierung
Was sich vernünftig automatisieren lässt, sollte automatisiert werden, und zwar an der frühestmöglichen Stelle. Eine Möglichkeit ist zum Beispiel das Axe-Figma-Plugin. Auch bei der Entwicklung ist es heute keine Option mehr, sondern ein Muss, diese Tools einzusetzen.
Auch gegen generative Technologien wie den Copilot von Microsoft ist generell nichts einzuwenden. Es nimmt den Entwicklerinnen ein wenig Zeit ab. Das heißt allerdings nicht, dass solcher code auch unkritisch übernommen werden sollte – das gilt eigentlich nie für generative Tools.
Last but not least ist auch nichts gegen automatisierte Tests einzuwenden, im Gegenteil. Laut einer Studie von Deque lassen sich ca. 2/3 der Probleme automatisiert aufspüren. Wenn diese zwei Drittel aufgespürt bzw. frühzeitig vermieden werden, dann sind wir schon einen Schritt weiter.
Die Standardisierung von Komponenten ist wie oben gesagt ein weiterer wichtiger Aspekt. Jeden Tag werden Komponenten entwickelt, bei denen man hinterher darüber nachdenkt, wie man sie barrierefrei machen kann. Standardisierung heißt nicht, dass alles gleich aussieht, sondern dass man erst die Komponente mit ihrer Funktionalität und Barrierefreiheit hat und sich hinterher überlegt, ob und warum man sie anders gestalten möchte. Ein wesentlicher Kostentreiber bei IT-Projekten sind die teils merkwürdigen Sonderwünsche der Kunden.
Annotations
Auch die Tools zum Kommentieren von Barrierefreiheits-Problemen scheinen in den letzten Jahren explosionsartig zugenommen zu haben. Annotations sollten aber immer der zweite oder dritte Schritt sein. Sie kennen das sicherlich: Einen Text voller Rechtschreibfehler zu korrigieren kostet deutlich mehr Zeit als einen mit wenigen. Im besten Fall sollten nur wenige Anmerkungen notwendig sein, weil Design und Entwicklung sauber gearbeitet haben.
Effiziente Kommunikation
Während sich Code standardisieren lässt, gilt das für die Sprache weniger. Die Tersterin möchte keine Romane schreiben, die Entwicklerin möchte sie nicht lesen. Also versucht man sich möglichst kurz zu fassen, was aber dazu führen kann, dass man falsch oder nicht verstanden wird. Im Endeffekt hat man keine Zeit gespart, weil weitere Schleifen notwendig werden.
Von dem her gilt, dass man sich möglichst klar und deutlich äußern sollte. Eine Text-Baustein-Verwaltung kann hier Zeit abnehmen. Es sind ja doch meistens die gleichen Dinge, die man vermitteln muss.
- Beschreibung des Problems
- Gewünschtes Verhalten
- mögliche Lösung
Generell ist mir aufgefallen, dass Kommunikation oft nicht effizient organisiert ist. Gemeint ist die projekt-orientierte Kommunikation, Kommunikation zur Beziehungs-Pflege ist ein anderes Thema. Man könnte hunderte an Stunden sparen, wenn hier vernünftig gearbeitet werden würde. Vielleicht helfen hier strikte Standards und ein klares Vokabular.
Auch für Barrierefreiheits-Expertinnen ist es eher tragikomisch, wenn sie Leute schulen oder Prüfberichte vorlegen und bei der nächsten Prüfung exakt die gleichen Fehler oft von den gleichen Leuten gemacht werden.
Sprache ist nicht perfekt und es können immer Mißverständnisse auftreten. Doch manchmal liegt es anscheinend doch daran, dass die Leute einfach nicht richtig mitmachen wollen oder können.
Agiles Projektmanagement
Der agile Projekt-Ansatz hat sich in der Software-Entwicklung durchgesetzt und kann sich auch für die Barrierefreiheit positiv auswirken. Kann, muss aber nicht. Meine Erfahrung ist hier nicht nur positiv.
Auch hier kann das Problem sein, dass die Barrierefreiheits-Expertinnen sehr spät im Entwicklungs-Zyklus eingebunden werden.
Pass-genaues Training
Trainings sollten so gestaltet werden, dass sie genau zum Gewerk passen. Aktuell gibt es entweder gar keine Trainings, was den Beteiligten den Einstieg schwer macht oder sehr große Trainings, die alle Gewerke in allen Bereichen bedienen wollen. Das funktioniert aber in der Regel nicht. Stattdessen sollten Designerinnen und Entwicklerinnen ihre jeweils eigenen Trainings bekommen.
Trainings sind allerdings nur die erste Stufe. Die Teilnehmenden sollten so geschult werden, dass sie in der Lage sind, Checklisten oder andere hilfreiche Tools effizient einzusetzen und ggf. selbst zu recherchieren. Bei Trainings ist das Problem, dass bei der ersten Durchführung vielleicht 30 Prozent hängen bleiben, manchmal sogar weniger. Man kann aber auch nicht jede Woche das gleiche Training durchlaufen. Hinzu kommt, dass Trainings einen Großteil der praktischen Probleme nicht erfassen können, weil sie zu kurz sind.
Ist der Erfolg damit garantiert?
Wenn wir diese Faktoren berücksichtigen, ist dann Erfolg garantiert? Leider nein, kein seriöser Mensch wird Ihnen für IT-Projekte eine Erfolgs-Garantie geben, zumindest nicht ohne Weiteres. Aber wenn ein paar wesentliche Faktoren beachtet werden, reduziert man den Overhead, der durch die Nicht-Berücksichtigung entsteht.