In vielerlei Hinsicht wird über Barrierefreiheit gesprochen und sie wird so umgesetzt, als wäre sie ein Hydra-Drache. Jedes Mal, wenn man glaubt, eine Verbesserung erzielt zu haben, schlägt man dem Barrierefreiheits-Drachen einen Kopf ab, und es wachsen zwei neue nach. Insbesondere gibt es viele Mythen, wonach Barrierefreiheit in einer agilen Entwicklungsumgebung nicht umsetzbar sei.
Das liegt zum großen Teil daran, dass Barrierefreiheit oft als etwas angesehen wird, das man manuell umsetzt, und zudem häufig nur im Rahmen von Nutzerakzeptanztests oder Usability-Tests. Das ist zwar ein wichtiger Aspekt der Barrierefreiheit, doch es gibt noch viel mehr, was Sie tun können, um Barrierefreiheit in Ihre agilen Prozesse zu integrieren und so barrierefreie Produkte zu entwickeln. Im Folgenden werden wir diese agilen Praktiken zur Transformation im Bereich Barrierefreiheit behandeln.
Agile Transformation
Dies ist ein sehr angesagter Begriff in den Entwicklerkreisen. Viele von euch haben dies bereits erlebt – oder den noch angesagteren Begriff „digitale Transformation“. Ein Unternehmen, das eine agile Transformation durchlaufen hat, weiß, dass es sich dabei um einen Veränderungsprozess handelt, der aktiv gesteuert werden muss. Bei der Barrierefreiheit wird oft nicht derselbe Ansatz verfolgt.
Wenn ich mit Leuten spreche und sie frage, ob sie sich um Barrierefreiheit kümmern, antworten sie oft: „Ja, wir kümmern uns um Barrierefreiheit.“ Wenn ich dann nachfrage, wie sie das handhaben, höre ich häufig etwas in der Art: „Ach, in unserer Done-Erklärung steht, dass wir die WCAG 2.0-Stufen A und AA einhalten müssen, und dann verlinken wir auf die W3C-Website.“ Das ist alles, was sie tun. Von den Entwicklern wird erwartet, dass sie sich das Thema Barrierefreiheit selbst aneignen, so wie sie es auch bei den meisten anderen Aspekten der Softwareentwicklung tun – etwa bei React, automatisierten Tests oder der Nutzung eines Continuous-Integration-Systems. Im Bereich Barrierefreiheit führt dieser Ansatz jedoch nur sehr selten zum Erfolg.
Im Grunde geht es darum, den Wandel zu bewältigen, wenn man eine Organisation so umgestaltet, dass sie statt unzugänglicher Software nun standardmäßig barrierefreie Software entwickelt. Dies erfordert eine Veränderung der Prozesse, der Arbeitsweisen und der Kompetenzen auf vielen Ebenen der Organisation.
Warum fällt diese Umstellung Organisationen ohne aktives Management so schwer? Schließlich wachen Entwickler morgens nicht mit dem Gedanken auf: „Ich gehe zur Arbeit und entwickle ein System, das 20 % der Bevölkerung ausschließt!“ Entwickler und Entwicklungsteams erstellen nicht barrierefreie Software, weil sie gar nicht wissen, dass dies ein Aspekt ist, auf den sie achten müssen.
Das ist zwar eine pauschale Verallgemeinerung, aber die meisten Entwickler kommen aus Bereichen, in denen sie keinen Kontakt zu Menschen mit Behinderungen haben. Dies ändert sich zwar langsam, da Google, Microsoft und andere große Akteure beginnen, sich verstärkt mit Barrierefreiheit zu befassen und ihr mehr Aufmerksamkeit zu schenken, doch es kommt nach wie vor sehr häufig vor, dass Entwickler keinerlei praktische Kenntnisse darüber haben, wie Menschen mit Behinderungen Technologie nutzen können und was sie tun müssen, um dies zu unterstützen.
Ein System der Empathie aufbauen
Der UX-Berufsstand hat auf der Grundlage von Experimenten und Beobachtungen einen umfangreichen Wissensschatz aufgebaut, der UX- und UI-Designern als heuristischer Leitfaden dient, um ansprechende, verständliche Anwendungen zu entwerfen, die die beabsichtigten Informationen vermitteln. Technologien wie Eye-Tracking, Klick-Tracking und Analysen liefern uns vielfältige Einblicke in das Nutzerverhalten. Für Menschen mit Behinderungen fehlen diese Informationen jedoch weitgehend. Wie „scannt“ ein blinder Nutzer die Seite? Wie navigiert er? Was macht „gutes Design“ für einen Screenreader aus?
Die meisten Entwickler wissen nicht, was ein Screenreader ist oder wie er verwendet wird, und sobald sie beginnen, sich damit auseinanderzusetzen, kommen ihre Gedanken ins Rollen. Wenn sie dann erkennen, dass es ihn gibt, müssen sie lernen, wie man für ihn gestaltet und wie man ihn implementiert. Dieses fehlende Wissen macht die „Empathie- und Kompetenzlücken“ aus.
Der erste Schritt zur Motivation ist das Interesse. Organisationen, die ein nachhaltiges Programm zur Barrierefreiheit aufbauen möchten, sollten systematisch daran arbeiten, diese Empathielücke zu schließen, da dies den Wunsch weckt, auch die Qualifikationslücke zu schließen.
Bei „ Deque “ gibt es zwei Maßnahmen, die wir recht häufig durchführen, um Empathie zu fördern. Die erste Maßnahme wird als „Empathie-Labor“ bezeichnet. Ein Empathie-Labor besteht aus einer Reihe von Aktivitäten, die verschiedene Arten von Behinderungen simulieren. Sobald die Teilnehmer diese praktischen Übungen durchlaufen haben, die darauf ausgelegt sind, ihnen Situationen näherzubringen, die in gewisser Weise den Auswirkungen einer Behinderung ähneln, beginnen sie, sich in andere hineinzuversetzen und Verständnis zu entwickeln.
Die zweite Maßnahme besteht darin, dass ein Entwickler einem Nutzer mit einer Behinderung (zum Beispiel einem Screenreader-Nutzer ohne Maus) dabei zusieht, wie dieser die von ihm entwickelte Software nutzt. Meiner Erfahrung nach gibt es nichts Eindrucksvolleres, als zu beobachten, wie jemand sich abmüht, das System zu bedienen, in dessen Entwicklung man unzählige Stunden, Wochen und Monate investiert hat. Ich habe schon erlebt, dass Entwickler direkt an ihren Arbeitsplatz zurückkehrten und sofort damit begannen, einige der Probleme zu beheben.
Wenn Ihr Unternehmen ein Programm einführt, bei dem Aktivitäten wie diese regelmäßig im Rahmen einer fortlaufenden Empathie-Kampagne stattfinden, schaffen Sie eine Kultur, in der Barrierefreiheit im gesamten Unternehmen großgeschrieben wird. Achten Sie darauf, Führungskräfte in diese Veranstaltungen einzubeziehen, um das Engagement der Führungsebene auf allen Ebenen zu stärken.
Barrierefreiheits-Coaches
Warum haben Profisportler, die auf dem Höhepunkt ihrer Karriere stehen, immer noch Trainer? Roger Federer gilt als der wohl beste Tennisspieler aller Zeiten, und dennoch hat er nach wie vor einen Trainer. Ein Grund, warum Sportler auf höchstem Niveau Trainer haben und von diesen profitieren können, ist, dass der Trainer eine andere Perspektive einbringt, die blinde Flecken in der eigenen Wahrnehmung des Sportlers aufdeckt. Wenn der Trainer zudem selbst ein wirklich guter Tennisspieler ist, kann er oder sie Roger auch dabei helfen, seine Fähigkeiten zu verbessern. Warum gibt es also keine Barrierefreiheits-Coaches für Entwickler? Wir bei Deque sind der Meinung, dass es sie geben sollte. Barrierefreiheits-Coaches sollten beim Aufbau des Barrierefreiheitsprogramms eingesetzt werden, ganz ähnlich wie Agile-Coaches bei einer agilen Transformation zum Einsatz kommen.
Barrierefreiheits-Coaches sollten gemeinsam mit der Organisation erreichbare Meilensteine festlegen, damit Teams ihre Erfolge feiern können, während sie auf vollständige Barrierefreiheit hinarbeiten. Diese Meilensteine sollten teamübergreifend einheitlich sein, damit sich die Teams miteinander vergleichen können und so ein gesunder Wettbewerb entsteht. Microsoft verwendet beispielsweise den Begriff „axe clean“ als einen Meilenstein bei der Entwicklung von UI-Code. Das bedeutet, dass der neue UI-Code keinerlei Probleme aufweisen darf, die mit der Axe-Analyse-Engine gefunden werden können. Die Festlegung eines Meilensteins, der sicherstellt, dass der gesamte neue UI-Code „axe-clean“ ist, stellt einen hervorragenden ersten Meilenstein auf dem Weg zur vollständigen Barrierefreiheit dar. Sobald ein Team dies über einen bestimmten Zeitraum hinweg erreicht hat, sollte gefeiert werden! Anschließend sollte der nächste Meilenstein festgelegt werden, um darauf aufzubauen. Ein guter nächster Meilenstein könnte die vollständig automatisierte Tastaturprüfung für alle interaktiven Funktionen sein. Die Meilensteine sollten im Voraus veröffentlicht werden, damit die Teams die Möglichkeit haben, die Ziele zu übertreffen. Der Barrierefreiheits-Coach sollte außerdem dabei helfen, ein Dashboard zu erstellen, um den Fortschritt bei der Umstellung auf Barrierefreiheit zu messen.
Barrierefreiheits-Coaches können zudem Stichproben zur Barrierefreiheit bei neuen UI-Funktionen durchführen, um die Ergebnisse an das Team weiterzugeben und so dabei zu helfen, Verbesserungsmöglichkeiten zu identifizieren. Sprint-Retrospektiven bieten hierfür einen guten Anlass, da sie dem Team die Möglichkeit geben, über die festgestellten Probleme zu sprechen, zu erörtern, wie sie sich verbessern können, ihre eigenen Kennzahlen zu betrachten und Änderungen an ihren Prozessen und Kompetenzen vorzunehmen (ein wesentlicher Bestandteil der agilen Arbeitsweise). Diese Kennzahlen und Retrospektiven sind nicht als Mittel zur Bestrafung oder Durchsetzung gedacht, sondern sollten als Benchmarking-Instrument genutzt werden, um Fortschritte zu verfolgen und Erkenntnisse für Verbesserungen zu gewinnen – was ein zentraler Bestandteil der agilen Philosophie ist.
TLDR: Zusammenfassung der Praktiken zur Umsetzung von Barrierefreiheit
Durch die Integration dieser Barrierefreiheitsmaßnahmen in Ihre agilen Prozesse können agile Teams den „Hydra-Drachen“ der Barrierefreiheit nachhaltig besiegen. Halten Sie Ausschau nach einem weiteren Beitrag zum Thema Barrierefreiheit, in dem wir uns mit Barrierefreiheit im Zusammenhang mit agilen Teampraktiken befassen werden.
Lassen Sie uns abschließend noch einmal die agilen Transformationspraktiken zusammenfassen:
- Bilden Sie ein zentrales Team, das die agile Transformation steuert und die verbleibenden Maßnahmen aus dieser Liste umsetzt.
- Führen Sie ein kontinuierliches Empathieprogramm durch, um die Motivation zu fördern und aufrechtzuerhalten.
- Eine Auswahl hochwertiger Lernressourcen zusammenstellen und zur Verfügung stellen sowie einige davon in das reguläre Einarbeitungsprogramm integrieren.
- Bilden Sie ein Team aus Barrierefreiheits-Coaches, um agile Teams zu betreuen.
- Erstellen Sie ein Dashboard zur Barrierefreiheit, um den Fortschritt der Veränderungen zu messen und den Teams sowie der Geschäftsleitung Bericht zu erstatten
