Barrierefreiheit: So machen Sie digitale Services für alle zugänglich

Barrierefreiheit bzw. Accessibility ist aktuell, weil im Juni der European Accessibility Act (EAA) der EU in Kraft getreten ist. Wie die DSGVO gilt der EAA nur für Schweizer Firmen, die in der EU Dienstleistungen anbieten. Aber auch hier gibt es einige Details zu beachten, auf welche später eingegangen wird. Zwei Auswirkungen bleiben: Erstens müssen einige Branchen, unter anderem Finanzinstitutionen, neu erstellte Webseiten barrierefrei anbieten, und zweitens müssen Projekte, welche Accessibility über Jahre vernachlässigt haben, für die EU-Zukunft fit gemacht werden. Das Ziel der Richtlinie ist, dass Benutzer mit einer Sehschwäche oder motorischen Behinderungen, aber auch ältere Personen digitale Dienstleistungen barrierefrei verwenden können. Wie dieses Ziel erreicht wird, ist weitgehend offen. In der Web-Entwicklung nennt man diese Anforderung «Barrierefreiheit». Auch ti&m hat in seiner Mobile- und E-Banking-Plattform ti&m Banking in einer aufwändigen Aktion das Feature «Barrierefreiheit» hinzugefügt.

Die grösste betroffene Gruppe sind Benutzer mit einer teilweisen oder vollständigen Farbenblindheit. Dies sind immerhin 8 Prozent der Männer und 0,5 Prozent der Frauen in Europa. Die zweitgrösste Gruppe sind Personen mit einer starken Sehschwäche. Diese müssen die Inhalte stark vergrössert darstellen können. Der wichtigste Beitrag zur Barrierefreiheit kommt somit von den Designern. Sie müssen sicherstellen, dass ihre Farbauswahl auch für Farbenblinde funktioniert. Alle Texte müssen einen Minimalkontrast zum Hintergrund aufweisen und auch im Dark oder Ultra High Contrast Mode noch gut lesbar sein.

Blinde Personen können keine Maus verwenden, weil sie den Mauszeiger nicht sehen. Diese Personen müssen eine Webseite ausschliesslich mit der Tastatur bedienen können. Es gibt auch Nutzer, die aus anderen Gründen keine Maus verwenden können, z. B. aufgrund körperlicher Einschränkungen. Für diese gibt es spezielle Eingabegeräte. Sehende Nutzer können mit dem Mauszeiger auf einer Webseite zweidimensional navigieren. Für Blinde hat eine Webseite eine lineare bzw. eine Baum-Struktur. Deshalb ist vollständige Tastaturbedienbarkeit ein wichtiger Punkt. Hier macht es einen grossen Unterschied, ob Barrierefreiheit von Anfang an eine Anforderung war oder nicht.

Die Nutzerführung per Tastatur muss beim Design ebenso eingeplant werden wie die Nutzerführung per Maus. Der Tastatur-Fokus muss sauber in Pop-ups und Dialoge übergeben werden und wieder an den richtigen Ort zurückspringen, wenn ein Dialog geschlossen wird.

Manchmal stellt sich heraus, dass ein Feature, welches für einen Kunden mit einem Designer ausgearbeitet worden ist und für sehende Nutzer intuitiv bedient werden kann, nicht barrierefrei gemacht werden kann. In dem Fall muss man das ganze Konzept in Zusammenarbeit mit dem Kunden überarbeiten und neu implementieren. Der mit Abstand aufwändigste Teil, um eine Webseite barrierefrei zu gestalten, ist die Unterstützung für Screenreader. Ein Screenreader ermöglicht es blinden Personen, einen Computer zu verwenden, und läuft im Betriebssystem, nicht direkt im Browser. macOS und iOS haben mit VoiceOver bereits einen beliebten Screenreader eingebaut. In der Schweiz sind die Softwares JAWS und NVDA für Windows ebenfalls sehr populär.

Um zu prüfen, ob eine Webseite oder Komponente barrierefrei ist, braucht es spezielle Tools und Erfahrung. Für normale Nutzer sind die barrierefreien Features verborgen. Nur wenn man die Webseite und Prozesse mit einem Screenreader testet, kann man sicherstellen, dass die Applikation auch wirklich von Blinden navigiert werden kann. Dies bedeutet auch, dass nicht nur Entwickler, sondern auch Product Owner und UX-Designer mit einem Screenreader umgehen können müssen.
 

Planung 
Die erste Hürde fängt bereits bei der Planung an. Das Team muss diese komplexe Aufgabe in kleine Stücke aufteilen. Aber wie?
Die Barrierefreiheit wird an der Einhaltung der WCAG-Regeln gemessen. Das sind z. B. die Einhaltung von Kontrastwerten, die Skalierbarkeit von Texten sowie die Verwendung von Alt-Text-Attributen für alle Bilder. Eine Aufteilung der User Stories nach WCAG-Regeln wäre aber verheerend. Dieser Ansatz funktioniert in der Praxis nicht, da jeder Entwickler bei praktisch jeder User Story einen grossen Teil der Codebasis ändern müsste. Eine Aufteilung, die am Aufbau einer Web-Applikation angelehnt ist, ist deutlich besser geeignet. Moderne UIs basieren auf einer hierarchischen Struktur von Komponenten. Jede einzelne Komponente, vom einfachen Button bis zur komplexen Landing-Page, kann schrittweise angepasst werden: zuerst die atomaren Komponenten wie Buttons oder Input-Felder und anschliessend die Kompositionen, bei denen mehrere Komponenten zusammen eine neue Komponente ergeben. Zusätzlich muss eine Reihe von Prozessen und Abläufen angepasst werden, welche nichts mit UI-Komponenten zu tun haben. Gerne geht auch vergessen, dass nicht nur die Web-Applikation, sondern auch alle herunterladbaren und verlinkten PDFs barrierefrei sein müssen. Oft stammen diese von Drittanbietern. Diese müssen auch in die Planung miteinbezogen werden.
 

Umsetzung 
Bei der Umsetzung ist es wichtig, dass sich Entwickler in die Lage von beeinträchtigten Nutzern versetzen können. Oft müssen sie improvisieren, denn die Dokumentationen der verschiedenen Experten – z. B. der WAI-ARIA-Gruppe, welche die barrierefreien Web-Standards betreut – sind oft unvollständig und manchmal widersprüchlich. Auch der für uns relevante Schweizer Accessibility Developer Guide wird nicht mehr proaktiv unterhalten und Korrekturen werden nur sporadisch veröffentlicht. Wer von Anfang an eine vollständig barrierefreie UI-Bibliothek einsetzt, kann mehrere Monate Arbeit einsparen. Ansonsten kommt man nicht darum herum, die gesamte UI-Bibliothek zuerst barrierefrei zu machen. Die WAI-ARIA-Spezifikation verbietet gewisse HTML-Strukturen, welche von Designern oft verwendet werden und vom Browser problemlos dargestellt werden können, z. B. verschachtelte interaktive Elemente, wie man sie oft bei kachelbasierten Designs findet. Eine Kachel ist verlinkt, enthält aber noch einen zweiten Link oder auch einen Menü-Button. 

Oft braucht es also nicht nur eine Anpassung am Code, sondern auch gleich Korrekturen am Design-System. Besondere Beachtung muss der Fokus-Kontrolle gewidmet werden. Wenn sich durch eine Nutzer-Interaktion ein Pop-up öffnet, muss der Tastatur-Fokus in das Pop-up verschoben werden. Wenn das Pop-up dann geschlossen wird, muss der Tastatur-Fokus wieder an einen sinnvollen Ort gesetzt werden. Diese Fokus-Kontrolle wird optimalerweise beim ersten Design definiert. Microfrontends, genauer die Web-Components-Technologie, stellen eine besondere Herausforderung dar. Durch sie werden Komponenten voneinander logisch unabhängig. Dies vereinfacht die Zusammenarbeit unterschiedlicher Teams, ist aber problematisch, wenn Komponenten logisch zusammengehören. ARIA-Tags funktionieren nicht über die Shadow-DOM-Grenzen der Web Components hinaus. Das WWW-Konsortium (W3C) ist sich des Problems bewusst und arbeitet seit 2017 an einer Lösung, dem Accessibility Object Model, welches bis heute ausstehend ist. Bei der Entwicklung der UI-Komponenten mit React wird meistens Storybook für die Darstellung der Komponenten in einem Design-System verwendet. Für Storybook gibt es ein Plugin, das Komponenten auf Barrierefreiheit testet. Dieses Plugin ist eine unerlässliche Hilfe.

Validierung 
Eine barrierefreie Seite sieht nachher immer noch gleich aus wie vorher. Auf den ersten Blick fallen nur kleine Detailänderungen auf – etwa, dass alle Buttons nun mindestens 24 x 24 Pixel gross sind. Für den Laien ist barrierefreie Technologie unsichtbar.
Mit einem Browser kann man Barrierefreiheit nur beschränkt testen. Es gibt aber einige Tests, mit denen man sehr schnell sehen kann, wie weit man mit der Barrierefreiheit ist. Ein erster Test ist, die Webseite ohne Maus und nur mit Tastatur zu bedienen. Wenn man alle User Flows durchspielen kann, ist man auf gutem Weg. Hier sollte man auch die Skip-Links sehen: ein UI-Element, welches die Nutzer die Titelelemente überspringen lässt und nur bei Tastatur-Fokus sichtbar wird. Ein weiterer Test ist, in den Browsereinstellungen die Standardschriftgrösse auf das Maximum zu setzen. Das Layout darf dadurch nicht brechen. In den Entwickler-Tools des Browsers (z. B. Lighthouse bei Chrome) ist ausserdem ein automatisierter Test enthalten, der prüft, wie gut die Webseite einen Satz von Regeln für Barrierefreiheit befolgt. Eine gute Punktezahl ist wichtig, bedeutet aber nicht, dass die Seite auch barrierefrei ist.

Dafür braucht es ergänzend ein manuelles Testing mit einem Screenreader. Testen muss man sowohl auf Desktop als auch auf Mobile. Viele Web-Entwickler verwenden Macs, und daher VoiceOver mit Safari. Unsere Erfahrung ist, dass Safari der Browser ist, der am besten mit VoiceOver funktioniert. VoiceOver gibt es natürlich auch auf iOS, dort funktioniert es aber anders als auf macOS. iPhones und iPads sind mittlerweile die beliebtesten Systeme bei Sehbehinderten für den Privatgebrauch. Für Windows gibt es die Screenreader JAWS und NVADA. JAWS ist teuer – für Sehbehinderte gibt es eine Vergünstigung, aber der Bezug für Entwickler ist kostspielig. Alternativ empfehlen wir, den freien Screenreader NVDA zu verwenden. Auf dem Mac kann man diesen in einer Windows-VM, z. B. VMware Fusion, betreiben. Diese enthält auch ein Windows, welches 30 Tage lang verwendet werden kann. Nachdem alles umgesetzt und intern getestet worden ist, muss die Applikation noch von Experten geprüft werden. Hier arbeiten wir erfolgreich mit Zugang für alle (Access for all) zusammen. Ihre Reporte sind gut geschrieben und lehrreich. Sie helfen den Entwicklern, die gefundenen Probleme schnell zu beheben und diese Fehler in späteren Projekten zu vermeiden.