Es könnte so einfach sein: HTML als Basis, hier und da ein wenig ARIA und schön machen mit CSS, fertig ist das barrierefreie Vorzeige-Produkt.
Kein Vorgehen nach Lehrbuch
Leider hat man selten die Möglichkeit, eine Anwendung von Scratch barrierefrei zu gestalten. Selbst Agenturen, die es besser wissen sollten bauen erst das Design und denken hinterher darüber nach, wie sie es barrierefrei machen.
In freier Wildbahn hat man es in der Regel mit fertigen Applikationen zu tun, die barrierefrei umgestaltet werden müssen. Das ist eine ganz andere und teils zähe Herausforderung. Darum geht es in diesem Beitrag. Vor allem möchte ich die Frage beantworten, warum ein einziger Test praktisch nie ausreicht und man nicht an der Projekt-Begleitung sparen sollte.
Barrierefreiheit ist nicht die einzige Anforderung
Digitale Produkte werden heute dynamisch weiterentwickelt. Bei größeren Produkten sind Entwicklungs-Zyklen von etwa drei Monaten üblich: Verbesserungen werden besprochen, entwickelt, geprüft, eventuell noch einmal nachjustiert und getestet und abschließend freigegeben. Oft werden mehrere Änderungen vorgenommen. Bezüglich der Barrierefreiheit heißt das, dass man zwei Schritte vor und einen halben zurück machen kann. Im Worst Case – das kommt meiner Erfahrung nach aber selten vor – kann ein Schritt vor und zwei zurück gemacht werden: Etwas wird optimiert, was aber durch eine andere Änderung komplett aufgefressen wird.
Man hat selten die Möglichkeit, nur Barrierefreiheit alleine und pur umzusetzen.
Barrierefreiheit in den Produkt-Zyklus hängen
Barrierefreiheit muss zu 100 Prozent in den Produkt-Zyklus integriert werden. Das heißt nicht, dass Barrierefreiheit immer 100 Prozent Priorität hat. Denken wir etwa anSicherheits- oder Datenschutz-Probleme, sie haben meistens Priorität. Aber Barrierefreiheit muss gleichberechtigt mit anderen Anforderungen eingegliedert sein.
Das erfordert in der Regel, dass man mindestens eine Person im Team hat, die sich sehr gut mit Barrierefreiheit auskennt. Oder dass alle im Team jeweils in ihrem Bereich wissen, worauf sie achten müssen.
Abnehmende Intensität im Projekt-Verlauf
Wurde ein Produkt nicht barrierefrei entwickelt oder wenn das Thema vernachlässigt wurde, nimmt die Barrierefrei-Machung gerade am Anfang sehr viel Zeit ein. In der Regel heißt das: Test – Optimierung, Test – Optimierung, Test – Optimierung, also drei Zyklen, bis man einen akzeptablen Stand erreicht hat.
Leider beauftragen viele Kunden nur einen Test und vielleicht einen Nach-Test, weil sie am falschen Ende sparen wollen oder glauben, ihre Teams kämen ohne eine Entwicklungs-Begleitung zurecht. Das Letztere ist meistens falsch: Ich habe noch kein Team gesehen, welches zufällig Barrierefreiheit drauf hat oder es intuitiv richtig macht. Es ist eine Sache, sich das Wissen für einzelne Komponenten draufzuschaffen. Das ist heutzutage dank guter Quellen oder ChatGPT kein Problem. Das Problem beginnt dann, wenn Erfahrung gefragt ist, zum Beispiel, wenn mehrere Komponenten zusammenspielen. Oder wenn die Entscheidung ansteht, welche Komponente angemessen ist. Spätestens die effiziente Nutzung eines Screenreaders für Test-Zwecke erfordert ein größeres Maß an Erfahrung.
Der Aufwand ist am Anfang am höchsten und sinkt im Laufe der Zeit: Am Anfang müssen sehr viele Probleme aufgespürt, dokumentiert und behoben werden. In dieser Phase ist auch der Support-Bedarf am höchsten. Der Bericht muss verstanden und die Issues korrekt umgesetzt werden. Das läuft eigentlich nie reibungslos wie bei allen komplexen und neuen Themen.
Die zweite Runde läuft in der Regel ein wenig besser: Es gibt dann schon erste Erfahrung im Team, Fehler des ersten Durchlaufs werden nicht mehr gemacht und das Team kennt sich schon besser, so dass die Zusammenarbeit runder läuft. Dennoch treten auch in dieser Phase Fehler auf.
Die dritte Phase ist die Konsolidierung: Man hat die gröbsten Schnitzer behoben, es geht nur noch um das Finetuning. Gehen wir vom oben genannten 3-Monats-Zyklus aus, sind also 9 Monate seit Kickoff vergangen.
Eine vierte Phase sollte es eigentlich nicht mehr geben: Vielmehr sollte man mit der Barrierefreiheit in den Regel-Betrieb gehen. In den weiteren Entwicklungs-Zyklen werden vielleicht noch kleine Probleme behoben, aber Barrierefreiheit wird immer berücksichtigt.
Meines Erachtens ist dieser Übergang von der Entwicklung in die Integration entscheidend für den Erfolg eines Projekts. Alles Andere hieße, dass man nach wenigen Entwicklungs-Zyklen wieder von vorne anfangen müsste, also im worst Case mit dem grundlegenden Barrierefreiheits-Test. Das Ziel muss also die permanente Integration in den Produkt-Zyklus sein. Das ist ein Fehler, der oft gemacht wird: Man sollte an den Tag danach denken und dafür planen, mit oder ohne Accessibility-Consultant.
Wissens-Verankerung
Im besten Fall hat man einen Accessibility Consultant im Projekt-Team. Mittlerweile bin ich recht skeptisch, was die permanente Verankerung von Expertise im bestehenden Produktions-Team angeht. Theoretisch ist das wohl möglich. In der Praxis scheitert es meistens. Möglicherweise liegt es daran, dass alle Bereiche für sich immer komplexer werden. Selbst Entwicklerinnen sind heute oft auf ein oder zwei Frameworks spezialisiert und durchschauen nicht mehr das gesamte Thema. Auch die Barrierefreiheit wird eher komplexer, so dass es für große Projekte ohne permanente Beteiligung zumindest eines Consultants vermutlich nicht gehen wird.
Das heißt allerdings nicht, dass der Consultant alles übernehmen muss bzw. immer und überall eingebunden sein muss. Vielmehr ist es seine Aufgabe, das Thema im Team so zu verankern, dass sie möglichst viel umsetzen können, ohne den Consultant jedes Mal zu kontaktieren: Der Prozess läuft dadurch besser und es treten weniger Verzögerungen durch Feedback-Schleifen auf. Drei Aufgaben fallen dabei an:
- Etablierung des Themas in den Design- und Development-Dokumenten und den Vorlagen/Komponenten-Bibliotheken
- Wissens-Aufbau im Team durch Learning by Doing oder Schulungen
- Etablierung von geeigneten Prüf-Tools, deren Verwendung und geeigneten Prüf-Routinen
Der Consultant verringert im besten Fall sein Engagement auf Beratung und Begleitung bei wichtigen und komplexen Fragen. Das ist auch deshalb sinnvoll, weil es oft ja mehrere komplexe Applikationen in einer Organisation gibt und auch seine Zeit begrenzt ist.