Heute geht es um Change Management in der digitalen Barrierefreiheit und warum das wichtig ist. Beim Change Management geht es darum, eine Organisation strukturell so umzugestalten, dass sie neue Aufgaben besser bewältigen kann. Für die Barrierefreiheit ist das besonders wichtig. Weil die größten Hürden meistens nicht technischer, sondern organisatorischer Natur sind.
Ausgangs-Thesen
Technische Probleme sind selten echte Blocker. Argumente wie „Das geht mit unserer Technik nicht“ oder „Das ist hart codiert“ überzeugen heute nicht mehr. Moderne Technologie-Stacks sind nicht monolithisch. Sie verändern sich ohnehin ständig. Wer mit diesem permanenten Wandel nicht umgehen kann, sollte keine Software veröffentlichen.
Das gilt auch für regulatorische Vorgaben. Man muss Gesetze wie die DSGVO oder Barrierefreiheitsanforderungen nicht mögen. Man muss sie aber trotzdem umsetzen.
Häufig wird behauptet, systemische Gründe würden die Digitalisierung oder die Barrierefreiheit verhindern. Das ist oft ein vorgeschobenes Argument. Wenn eine Regierung von systemischen Gründen spricht, vergisst sie: Sie ist selbst Teil des Systems und kann es ändern. Das gilt erst recht für Unternehmen. Wenn eine Organisation behauptet, sie könne Strukturen wegen alter Gewohnheiten nicht ändern, ist sie unflexibel. Barrierefreiheit ist dann meistens nur eines von vielen Problemen.
Deshalb schauen wir uns heute die konkreten strukturellen Blockaden an – und wie wir sie beheben können.
Blocker „Das betrifft unsere Kunden nicht“
Im E-Commerce ist ein Gedanke bei Verantwortlichen weit verbreitet, den kaum jemand laut ausspricht: „Blinde Menschen nutzen keine Computer. Und selbst wenn, kaufen sie unsere Produkte nicht.“ Man geht beispielsweise davon aus, dass blinde Menschen keine Marken-Laufschuhe kaufen.
Durch das Barrierefreiheitsstärkungsgesetz (BFSG) ist E-Commerce nun gesetzlich zur Barrierefreiheit verpflichtet. Das verringert den Diskussionsbedarf. Dennoch bleibt Überzeugungsarbeit wichtig.
– Wissen vermitteln: Selbst hochgebildete Menschen wissen oft nicht, dass Menschen mit Blindheit oder Querschnittslähmung Computer nutzen.
– Zielgruppen erweitern: Viele Menschen sind technikunaffin oder im Alter mit komplexen Online-Shops überfordert. Ältere Menschen sind jedoch eine enorm wichtige Zielgruppe für das Online-Shopping.
– Technik erlebbar machen: Ein spielerischer Ansatz hilft. Lassen Sie Verantwortliche einen Screenreader auf dem eigenen Smartphone testen. Das fasziniert und schafft Verständnis.
– Den persönlichen Bezug herstellen: Viele Entscheidungsträger sind in ihren 30ern oder 40ern. Ihre Eltern oder Großeltern haben oft Sehschwächen oder Probleme mit modernen Interfaces. Wer ihnen die Bedienungshilfen des Smartphones zeigt, schlägt eine Brücke zur eigenen Familie.
Die Kernfrage für Verantwortliche lautet: „Möchtest du, dass deine eigenen Großeltern oder Eltern den von dir gebauten Online-Shop nutzen können? Oder ist dir das egal?“
Am Ende ist digitale Barrierefreiheit eine Frage der Empathie. Jeder Mensch sollte prinzipiell die Möglichkeit zur Teilhabe haben – ob er am Ende die Laufschuhe kauft oder nicht.
Ein starkes Bewusstsein für die Probleme und Bedürfnisse der Zielgruppe weckt oft den Ehrgeiz des Teams. Viele Entwicklerinnen und Designerinnen wollen, dass möglichst viele Menschen ihre Anwendung nutzen können. Im E-Commerce funktioniert dieser empathische Ansatz meistens gut. Der Eye-Opener ist, wenn man behinderten Menschen dabei zusieht, wie sie die Anwendung nutzen oder daran scheitern.
Im Online-Banking ticken die Verantwortlichen oft anders. Hier zieht das Empathie-Argument seltener. Stattdessen greift das rechtliche Argument (Legal Argument). Die strengen gesetzlichen Vorgaben im Bankensektor zwingen die Verantwortlichen zur konformen Umsetzung – selbst wenn sie es persönlich nicht für sinnvoll halten. Auch hier ist Sennsibilisierung trotzdem sinnvoll.
Blocker: Barrierefreiheit als „Low Priority“ am Projektende
Ein bekanntes Phänomen: Barrierefreiheit wird als unwichtiges Thema ans Ende des Projekts geschoben. Das Produkt ist fertig, der Launch ist für nächste Woche geplant, und erst dann wird die Barrierefreiheit geprüft.
Das Ergebnis ist meistens eine Liste mit 50 Mängeln. Die Behebung sprengt jeden Zeitrahmen. Da die Barrierefreiheit aber gesetzlich vorgeschrieben ist, verzögert sich der Launch massiv. Das passiert leider selbst in Organisationen, die es eigentlich besser wissen müssten.
Barrierefreiheit muss strukturell verankert werden. Sie gehört fest in die Design- und Entwicklungs-Pipelines:
– Design-Pipelines: Feste Kriterien in Design-Bibliotheken und Styleguides verankern.
– Developer-Pipelines: Barrierefreiheits-Vorgaben in Entwickler-Bibliotheken integrieren.
– Automatisierung: Automatisierte Barrierefreiheitstests direkt in die CI/CD-Pipeline einbinden. Das fängt einen Großteil der Fehler präventiv ab.
– Austausch: Regelmäßige Absprachen mit Barrierefreiheitsexperten etablieren.
Ein weiteres Priorisierungsproblem entsteht durch den Drang nach neuen Funktionen. Ständig sollen neue Features eingebaut werden. Das Thema Barrierefreiheit rutscht dadurch auf der Roadmap immer weiter nach hinten.
Häufig betrifft das extern eingekaufte Lösungen von Drittanbietern, wie zum Beispiel:
– Video-Player und Streaming-Tools
– Chatbots
– Iframes für Zahlungslösungen
Diese Tools sind wichtig, müssen aber zwingend barrierefrei sein. Barrierefreiheit ist keine optionale Schicht (wie ein Overlay), die man am Ende einfach über das Produkt stülpt.
Wenn wir Barrierefreiheit früh in die Pipeline integrieren, Kompetenzen aufbauen und Drittlösungen streng prüfen, ist das Problem fast gelöst. Am Ende braucht es jedoch ein klares Qualitätstor (Quality Gate): Wenn ein neues Feature nicht barrierefrei ist – oder zumindest die automatische Prüfung fehlschlägt –, wird die Veröffentlichung blockiert. Das Release geht erst live, wenn die Barrierefreiheit nachgebessert wurde.
Blocker fehlende Kompetenz
Mangelndes Wissen ist derzeit einer der größten Blocker. Wir können dieses Problem nicht kurzfristig lösen, aber wir können es gezielt angehen. Es ist sinnvoll, Barrierefreiheitsexperten im Team zu haben. Das reicht aber nicht aus. Wir brauchen eine rollenspezifische Qualifizierung. Viel Widerstand gegen Barrierefreiheit kommt aus mangelndem Umsetzungs-Wissen. Insofern ist Wissens-Vermittlung auch Empowerment.
– Designerinnen müssen wissen, wie barrierefreies Design funktioniert.
– Entwicklerinnen müssen wissen, wie barrierefreier Code geschrieben wird.
Niemand muss im Alleingang zur allwissenden Expertin werden. Aber jede Person sollte in ihrem eigenen Fachbereich so qualifiziert sein, dass sie Barrierefreiheit von Anfang an mitdenken und umsetzen kann. Das spart Zeit und Frust.
h2>Blocker Warum müssen wir das machen
Es ist verständlich, dass viele Beteiligte das Thema Barrierefreiheit frustrierend finden. Es ist nun mal komplex. Diese Frustration lässt sich jedoch gezielt abbauen, indem wir nicht nur Kompetenzen schaffen, sondern das „Warum“ erklären. Viele Barrierefreiheits-Anforderungen sind aus sich heraus nicht verständlich.
Es reicht nicht zu sagen: „Das ist Gesetz, das müssen wir so machen.“ Besser ist es, den konkreten Impact aufzuzeigen.
Praxistipp für Jira-Tickets und Prüfberichte:Ergänze Fehlerbeschreibungen immer um die Auswirkung:
• „Wenn du dieses Feature barrierefrei umsetzt, hat das diesen positiven Impact…“
• „Wenn wir es so lassen, hat das diese konkrete negative Konsequenz für die Nutzer…“
Wenn Entwicklerinnen und Designerinnen verstehen, warum eine Funktion wichtig ist, weckt das ihr Verständnis. Und es hilft ihnen, es beim nächsten Mal direkt richtig zu machen.
Blocker Kreativität
Ein häufiges Argument lautet: „Barrierefreiheit schränkt meine gestalterische Freiheit und Kreativität ein.“ Entwicklerinnen bauen gerne coole, maßgeschneiderte Features. Eine Standard-Checkbox oder ein klassisches HTML-Eingabefeld wirken da schnell langweilig.
Das ist jedoch ein Fehlschluss, der oft durch den blinden Einsatz moderner Frameworks und vorgefertigter Design-Bibliotheken entsteht.Fakt ist: HTML5 und CSS3 bieten heute unzählige Möglichkeiten, Standard-Elemente umfassend und modern zu gestalten. Dafür muss man sich allerdings mit den Grundlagen auskennen. Man darf von Profis erwarten, dass sie nicht nur die Checkbox aus Bootstrap kopieren, sondern die Web-Basics beherrschen.
Vor 10 bis 15 Jahren gab es diese überfrachteten Frameworks noch gar nicht. Wir haben trotzdem ansprechende Oberflächen gebaut, ohne dass das Design darunter gelitten hat. Hier muss ein echtes Umdenken stattfinden: Weg von aufgeblähtem Legacy-Code oder Bequemlichkeit, zurück zu sauberem, nativem Code.
Das Argument, die Entwicklung mit nativem HTML und CSS dauere länger, ist objektiv meist falsch. Wer ein komplexes Framework nutzt, muss sich erst einarbeiten, dessen Spezialitäten beherrschen und am Ende mühsam überlegen, wie man das Konstrukt irgendwie barrierefrei bekommt. Ein sauberes HTML-Element mit CSS zu stylen, ist oft schneller und nachhaltiger.
Zudem arbeiten größere Organisationen heute ohnehin mit Komponenten-Bibliotheken. Das bedeutet: Eine barrierefreie Checkbox muss nur ein einziges Mal richtig gebaut werden.
Danach kann sie im gesamten System immer wieder verwendet werden.
Bei den nächsten Iterationen muss niemand das Rad neu erfinden. Der Aufwand sinkt gegen null. Frameworks hingegen benötigen regelmäßige Updates und Sicherheits-Checks.