Barrierefreiheit ist längst kein „Nice-to-have“ mehr. Sie ist ein zentraler Bestandteil moderner Softwareentwicklung. Ihre Umsetzung ist keine einmalige Aufgabe, sondern sie muss im gesamten Lebenszyklus digitaler Produkte verankert werden. Dass dies bei der Weiterentwicklung unseres Webclients eine große Herausforderung darstellt, haben auch wir bei der d.velop AG zu spüren bekommen. Unsere Software ist durch die Telekom MMS als barrierefrei zertifiziert.
Wie wir das geschafft haben, ist Thema der Serie „Barrierefreiheit @ d.velop“. In diesem ersten Teil erfährst du, wie sich unser Prozess entwickelt hat, um Barrierefreiheit nutzerorientiert, rechtskonform und nachhaltig umzusetzen.
Was bedeutet Barrierefreiheit eigentlich?
Durch rechtliche Bestimmungen wie die BITV 2.0, der EN 301549, das BGG und das BFSG sind alle öffentlichen Stellen und große private Unternehmen zu Barrierefreiheit verpflichtet. Was genau das im digitalen Raum bedeutet, dazu könnte man ganze Bücherregale füllen. Patrick Dressler hat sich in diesem Blogbeitrag genauer damit beschäftigt. Im Grunde geht es darum, allen Menschen die Nutzung unserer Software zu ermöglichen – unabhängig von individuellen Einschränkungen. Angefangen bei eingeschränktem Sehvermögen oder Blindheit über Hörbeeinträchtigungen, motorische Einschränkungen und Epilepsie bis zu kognitiven Beeinträchtigungen wie ADHS, Legasthenie oder Demenz. Das Spektrum an Betroffenen ist sehr vielfältig.
Es ist wichtig zu verstehen, dass Barrierefreiheit nicht nur ein Extra für Menschen mit Behinderungen darstellt. Nach dem Prinzip des Universal Designs profitieren wir alle davon. Barrierefreie Software erleichtert den Umgang mit alltäglichen Herausforderungen – sei es bei blendendem Sonnenlicht, der Nutzung auf mobilen Endgeräten, der effizienten Bedienung ausschließlich per Tastatur oder, vor dem Hintergrund des demografischen Wandels besonders wichtig, bei der Nutzung im höheren Alter.
Zahlen, Daten und Fakten rund um Barrierefreiheit und Software
Barrierefreiheit als Gemeinschaftsprojekt: Der Arbeitskreis bei d.velop
Als die Anforderung „Barrierefreiheit“ bei uns im Entwicklerteam eintraf, kamen zunächst viele Fragen auf:
- Was bedeutet das konkret?
- Wie kann ich das umsetzen?
- Wie kann ich das testen?
Um diesen und noch weiteren Fragen zu begegnen, haben wir einen Arbeitskreis gegründet, der noch heute Bestand hat. In diesem ist aus jedem Team, das Benutzeroberflächen entwickelt, eine Person vertreten. Gemeinsam sind wir in das Thema eingestiegen, haben uns eingelesen und an Schulungen teilgenommen. Wir haben uns über die Anforderungen und mögliche Lösungswege ausgetauscht, Entscheidungen zur einheitlichen Umsetzung getroffen und einander bei Problemen unterstützt.
Durch den Arbeitskreis werden Wissen und Lösungen fortlaufend gebündelt, konserviert und gestreut. Die Mitglieder wurden mit der Zeit zu „Barrierefreiheits-Experten“ und können das Thema in ihren Teams vertreten. Gleichzeitig ist uns bewusst, dass niemand alles über Barrierefreiheit und barrierefreie Softwareentwicklung wissen kann. Dazu ist das Thema einfach zu groß. Deshalb ist der Arbeitskreis auch weiterhin unser wichtigstes Werkzeug, um Barrierefreiheit langfristig zu gewährleisten.
Anforderungen und Entscheidungen auf dem Weg zur barrierefreien d.velop Software
Durch das breite Spektrum an Betroffenen müssen viele Dinge berücksichtigt werden. Zum Glück gibt es klare Standards für barrierefreie Software. Die Bestimmungen der BITV 2.0 und EN 310549 sind größtenteils durch die WCAG 2.1 abgebildet.
Die WCAG 2.1 ist ein internationaler Standard, welcher anhand von 78 Kriterien die barrierefreie Gestaltung digitaler Angebote beschreibt. Damit hatten wir eine solide Grundlage für unsere Anforderungen. Die einzelnen Kriterien haben wir zunächst grob angeschaut und nach dem Ansatz zur Umsetzung gruppiert:
- Kontraste: Farbgestaltung dynamisch umsetzen
- Tastatursteuerung: Elemente und Aktionen ohne Maus zugänglich machen
- Screenreader-Fähigkeit: Elemente und ihre Beziehungen durch ARIA-Attribute beschreiben
- Leichte Verständlichkeit: Klare Strukturen, Erklärungen und Dokumentationen
- Reiz-Reduktion: Unnötige Dinge ausblenden
- Zoom: Responsive Design on Overdrive
Angefangen bei den Kontrasten hat der Arbeitskreis begonnen, die Themen zu diskutieren. Manche sind durch die Understanding- und How-to-Meet-Leitfäden der WCAG eindeutig. Ein Beispiel dafür ist das Kriterium 3.1.1 Language of Page. Um es zu erfüllen, muss das lang-Attribut am <html>-Tag gesetzt werden. Andere lassen etwas Spielraum, wie etwa 2.4.3 Focus Order. In Toolbars könnte der Fokus per Tab oder per Pfeiltasten zwischen den einzelnen Elementen bewegt werden. Zu solchen Kriterien haben wir verschiedene Lösungen evaluiert, oft auch in Abstimmung mit externen Beratern, und uns auf eine Entscheidung geeinigt. Diese wurde dann als klare technische Anforderung in unserer Knowledge Base dokumentiert:
„Per Tab soll auf das erste Element in der Toolbar gesprungen werden. Zwischen den einzelnen Elementen innerhalb der Toolbar wird mit den Pfeiltasten navigiert. Wird erneut Tab gedrückt, wird das nächste interaktive Element nach der Toolbar fokussiert. Wird die Toolbar per Shift + Tab angesteuert, wird das Element der Toolbar, welches zuletzt fokussiert war, fokussiert.“
Dadurch verringern wir die Komplexität in der Umsetzung und stellen sicher, dass unsere Software sich an allen Stellen gleich verhält.
Die Anforderungen verstehen: Gespräche und Tests mit Betroffenen
Unabhängig von den konkreten Anforderungen gab es noch eine andere Schwierigkeit: Als sehende Person kann man gar nicht nachvollziehen, wie eine blinde Person mit unserer Software arbeitet. Wir können zwar die WCAG lesen, aber erst durch Gespräche und Tests mit Betroffenen haben wir wirklich verstanden, wie die verschiedenen Zielgruppen arbeiten und wie wir ihnen am besten helfen können. Ich selbst habe mit mehreren blinden und sehbeeinträchtigten Personen sprechen dürfen und empfand das als extrem wertvoll, sowohl auf fachlicher als auch persönlicher Ebene.
Denn durch solche menschlichen Erfahrungen bekommt das Thema ein Gesicht – wir machen das nicht nur, um BITV konform zu sein, sondern um Menschen zu helfen!
In diesem Interview kannst auch du aus erster Hand erfahren, wie eine blinde Person mit einem Computer und d.velop Software arbeitet.
„Und täglich grüßt die Barrierefreiheit“ – wie d.velop documents barrierefrei wurde
Unser Weg hin zur zertifizierten Barrierefreiheit war nicht kurz und alles andere als geradlinig. Wir haben uns in einem iterativen Prozess aus Analyse, Konzipierung, Umsetzung und Prüfung immer weiter hin zu einer barrierefreien Anwendung bewegt. Der Arbeitskreis war dabei der Dreh- und Angelpunkt.
Im ersten Schritt ging es an die Anforderungsanalyse. Dabei wurden wir von externen Spezialisten beraten und standen in regem Austausch mit den Prüfern. Freundlicherweise wurden wir auch von einigen Mitarbeitenden unserer Kunden unterstützt, die selbst von Einschränkungen betroffen sind. So haben wir für die Lösungsfindung verschiedene Kanäle berücksichtigen können und im Arbeitskreis fundierte Entscheidungen zur Umsetzung der Kriterien getroffen.
Diese Lösungskonzepte haben die Teams dann umgesetzt und wir haben unsere Software zur Prüfung gegeben. Beim ersten Durchlauf sind wir allerdings durchgefallen. Es kam eine lange Liste mit Fehlern zurück. Diese haben wir dann wieder analysiert, umgesetzt und zur Prüfung gegeben. Und von da kam dann die nächste Liste an Fehlern zurück.
Dieser Kreislauf hat sich über fast zweieinhalb Jahre erstreckt. Immer wieder kamen neue Dinge auf und teils gab es auch widersprüchliche Findings in verschiedenen Bereichen. So hat sich das Thema über einen längeren Zeitraum erstreckt als ursprünglich angenommen.
Der Grund dafür liegt in der Komplexität des Themas. Man kann die WCAG formalistisch umsetzen, sodass die Kriterien erfüllt sind. Allerdings bedeutet das noch nicht, dass die Software beispielsweise für eine blinde Person nutzbar ist. Sowohl bei uns als auch in der Prüfung hat es einige Zeit gedauert, bis wir den richtigen Modus gefunden und uns auf einen Nenner geeinigt haben. Dass wir in stetem Austausch mit den Prüfern und den beteiligten Kunden standen, hat uns dabei auf jeden Fall sehr geholfen.
Als Learning haben wir mitgenommen, dass die genaue Kommunikation von Anforderungen und Fehlern sowie der Scope (welche Bereiche der Software, welche Browser, welche Screenreader, …) klar kommuniziert werden müssen. Den Arbeitskreis und die herausragende teamübergreifende Zusammenarbeit haben wir durchgehend als sehr positiv wahrgenommen. Außerdem haben wir schon nach den ersten Prüf-Iterationen die Rückmeldung von Betroffenen bekommen, dass sie nun deutlich besser mit unserer Software arbeiten können. Solche Dinge haben unsere Motivation bei all den Herausforderungen aufrechterhalten.
Barrierefreiheit langfristig denken und nachhaltig in der Softwareentwicklung leben
Mit dem Erlangen des Zertifikates sind wir nicht am Ende des Themas „Barrierefreiheit“ angelangt. Der Prozess sieht heute aber anders aus, da keine externen Prüfer mehr beteiligt sind. Barrierefreiheit muss von unserer Seite nachhaltig und langfristig im Entwicklungsprozess verankert werden. Dazu haben wir sie als weitere Säule der Qualität unserer Software etabliert. Sie steht auf einer Ebene mit Themen wie Usability, Security oder Performance.
Für Weiterentwicklungen oder neue Features muss Barrierefreiheit also zwingend beachtet werden. Das war anfangs schwer, doch je tiefer man im Thema ist, desto mehr denkt man Barrierefreiheit direkt bei der Umsetzung mit. Dennoch hat es sich bei uns etabliert, einen Puffer von ungefähr einer Personen-Woche am Ende von Neuentwicklungen dafür einzuplanen.
Der Arbeitskreis hat sich auch in diesem Prozess als sehr effektiv bewährt. Wenn ein Team vor einer Frage zur Barrierefreiheit steht, wendet es sich an den Arbeitskreis. Hat sich ein anderes Team bereits mit der Problematik beschäftigt, wird es direkt bei der Lösung unterstützen. Andernfalls werden sich mehrere Leute melden, um das Thema zu diskutieren und eine Entscheidung festzuhalten. Die Teilnahme an solchen Diskussionen ist freiwillig, aber bisher haben sich immer mindestens zwei oder drei Personen gefunden. Das zeigt, dass Barrierefreiheit bei vielen unserer Kollegen:innen einen hohen Stellenwert hat. Und darauf können wir – finde ich zumindest – stolz sein.
Für Neueinsteiger in das Thema ist der Arbeitskreis als Wissensspeicher allerdings nicht ausreichend. Die Leute müssen sowohl theoretisch als auch praktisch an das Thema herangeführt werden. Dafür haben wir erst kürzlich einen Workshop mit mehreren Teams organisiert. In zwei Tagen wurde ihnen theoretisches und praktisches Wissen vermittelt, wie sie ihre Anwendungen barrierefrei machen können.
Rückblick auf unsere Erfolgsstory zur Barrierefreiheit der d.velop Software
Barrierefreiheit ist ein sehr umfassendes Thema und sie umzusetzen erfordert viel Zeit und Aufwand, das können und wollen wir gar nicht schönreden. Aber trotz des anspruchsvollen Weges ist sie bei uns zu einer echten Erfolgsstory geworden. Zum einen sind wir als barrierefrei zertifiziert und erfüllen so die Grundlagen für Software im öffentlichen Bereich, zum anderen sind wir uns auch der moralischen Verantwortung bewusst, die Digitalisierung als Chance für bessere Inklusion zu nutzen.
Mit dem Arbeitskreis haben wir gute Erfahrungen zur Wissenssammlung und -verteilung gemacht. So können wir langfristig mit dem Thema umgehen. Gerade der Aspekt der teamübergreifenden Zusammenarbeit funktioniert dort außerordentlich gut. Und die über unseren Prozess getroffenen Entscheidungen haben sich bisher sowohl in formalen Prüfungen als auch in praktischen Tests bewährt.
Falls du mehr Einblicke erhalten möchtest, wie Barrierefreiheit bei uns gelebt wird, halte Ausschau nach zukünftigen Blogbeiträgen der Serie “Barrierefreiheit @ d.velop”.
Dein Job bei der d.velop wartet auf Dich!
Du möchtest Teil des Teams werden? Wir freuen uns immer über Talente, die mit uns gemeinsam daran arbeiten, die Geschäftsprozesse in Unternehmen digital zu gestalten.