Barrierefreiheit ist ein Mannschaftssport!

Und tatsächlich hat sich in den letzten Jahren auch im Bereich interner Anwendungen schon einiges in Sachen Barrierefreiheit getan; was angesichts eines Anteils von fast 8 Prozent Beschäftigten mit Behinderung in Bundesbehörden auch dringend nötig ist. Doch wenn man genauer hinsieht, ist nicht überall wo „barrierefrei“ draufsteht auch wirklich „barrierefrei“ drin.
Denn auch hier steckt die Tücke oft im Detail. Allzu häufig wird das Thema Barrierefreiheit zu Projektbeginn erst einmal hintenangestellt und auf später verschoben. Warum das so ist und worauf man beim Entwurf und Aufbau einer barrierefreien internen Anwendung achten muss, erklären SEITENBAU Geschäftsführer Florian Leinberger und Barrierefreiheit-Experte Martin Mengele. Das Interview führte Dominik Kraus.

Herr Leinberger, Herr Mengele, Sie entwickeln gerade mit Social OfficeNet (SON) eine komplexe interne Portalanwendung, die gemäß BITV barrierefrei sein muss. Wie definiert sich aus Ihrer Sicht eine „barrierefreie“ Software?

Martin Mengele: Die Barrierefreiheit der Software hängt entscheidend von ihrer „Maschinenlesebarkeit“ ab. Darunter versteht man den Grad, wie Dritt-Software die von uns entwickelte Software verstehen kann. Angenommen, wir würden in unserem Intranetportal Texte nur als Bilder von Texten veröffentlichen. Dann könnten sogenannte Screenreader, die den Bildschirminhalt vorlesen, zum Beispiel für blinde Nutzer, diese nicht erfassen und der Inhalt ginge verloren. Oder Stellen Sie sich eine Schaltfläche (Button) für das Löschen eines Dokuments vor, die nur optisch mit dem Symbol „Papierkorb“ belegt wird. Das kann eine Person, die einen Screenreader bedient, nicht ohne weiteres erfassen. Wir hinterlegen dafür dann einen zusätzlichen Text „Dokument löschen“, damit alle Nutzer verstehen können, was damit gemeint ist. Alle Inhalte müssen eben auch als Text wahrnehmbar für alle Nutzer vorliegen.

Ein Kernthema ist die Art und Weise, wie Nutzer unsere Software bedienen. Beispielsweise nutzte der Physiker Professor Steven Hawking einen sogenannten „Switch“. Das ist eine Vorrichtung, die es ermöglicht, die interaktiven Elemente und Texte auf einem Bildschirm zu erforschen, indem man den Fokus durch spezielle Impulse wie Muskelbewegungen innerhalb der Software fortbewegt. Im Falle von Hawking steuerte er dies allein über Impulse aus seinem Wangenmuskel. Eine derartige Steuerung in einer Webapplikation zu ermöglichen, ist recht einfach - nur muss sie von Anfang an in alle Überlegungen zur Navigation und Steuerbarkeit einfließen. Ein Bonus der Berücksichtigung dieser Besonderheiten ist, dass die Software dadurch auch durch Sprachsteuerungssoftware bedient werden kann. „Alexa, klick auf Startseite!“ würde bei unserer Software wahrscheinlich funktionieren (lacht). Wir haben allerdings bisher nur Steuerungssoftware für den Gebrauch im Office-Umfeld getestet und das hat sehr gut funktioniert. Siri von Apple würde sicher auch gut damit zurechtkommen (grinst).

Was ist besonders schwierig umzusetzen? 

Martin Mengele: Eines der schwierigsten Themen ist die Verständlichkeit der Inhalte. Dies ist oft ein redaktionelles Thema, da die Inhalte ja von Nutzern erstellt werden. Im Behördenumfeld, wo wir uns mit Social OfficeNet bewegen, ist das oft nicht so einfach. Oder wenn es darum geht, Fachbegriffe verständlich zu machen. Wir schaffen da nur den Rahmen, aber auch der muss verständlich sein. Das erreicht man meist durch Konsistenz und durch Auswertung von Usability-Tests mit echten Nutzern.

Welche Arten von Einschränkungen werden berücksichtigt?

Martin Mengele: Eine besondere Rolle spielen bei uns alle Beeinträchtigungen des Sehens. Vor allem die Lesbarkeit der Inhalte ist wichtig. Aber nicht nur Maschinen, vor allem Menschen müssen die lesen können.

Unser Portal muss deshalb auch immer dynamisch im Browserfenster vergrößert werden können, damit auch stark kurzsichtige Menschen alle Inhalte erfassen können. Oder Fehlermeldungen dürfen nicht nur einfach mit rotem Text dargestellt werden. Es gibt immer noch zusätzlich ein Symbol „Fehler“, so dass auch farbfehlsichtige Menschen auf den ersten Blick erkennen können, dass die Applikation eine Fehlermeldung ausgegeben hat.

Aber wir umfassen mit unseren Überlegungen auch Situationen, die als solche vielleicht nicht im Volksmund unter dem Begriff „Behinderung“ subsumiert werden. Stellen Sie sich vor, Sie sitzen mit Ihrem Laptop in einem sehr dunklen Raum und sind stark geblendet von der hohen Helligkeit zum Beispiel in Word mit schwarzem Text auf weißem Grund. Im Betriebssystem Windows kann man in solchen Situationen in einen abgedunkelten Modus umschalten. Wir bauen unsere Applikation so auf, dass sie ebenfalls damit zurechtkommt und weiter bedient werden kann.

Ich selbst habe erst kürzlich versucht, die Applikation nur mit einer sogenannten Kamera-Maus zu steuern. Man aktiviert dazu die Webcam an seinem Laptop und die Software erkennt, wo der Blick des Nutzers gerade auf dem Bildschirm ist und steuert so den Mauszeiger. Man kann das so einstellen, dass dann ein Zwinkern einen Klick auslöst. Das ist zwar für Ungeübte sehr mühsam, aber so können wir sicherstellen, dass auch Menschen mit motorischen Einschränkungen oder Lähmungen, die vielleicht nur noch den Kopf bewegen können, mit unserer Applikation arbeiten können. Man macht sich dann so Gedanken wie „Sollten wir nicht diese Schaltfläche hier viel größer machen, damit das mit einer zittrigen Kamera-Maus bedienbar ist?“ So gewinnt man jedenfalls eine ganz neue Perspektive und viel an Empathie dazu.

In Planung ist es zudem, Inhalte in leichte Sprache und in Gebärdensprache zu ermöglichen. Dazu muss die Möglichkeit geschaffen werden, Videos mit Gebärdensprache zu hinterlegen.

Wie geht man bei einem solchen Projekt am besten vor? Braucht man eine dezidierte Barrierefreiheit-Beauftragte oder Beauftragten? Und ab welchem Zeitpunkt sollten diese aus Ihrer Sicht in das Projekt einbezogen werden?

Florian Leinberger: Auch wenn Barrierefreiheit eine gesetzliche Vorgabe ist, sollte man schon zu Beginn des Projekts mit dem Auftraggeber klären, wie wichtig ihm dieses Qualitätsziel für die konkrete Anwendung tatsächlich ist und welche Maßnahmen und Ressourcen zur Erfüllung eingesetzt werden sollen. Ein gemeinsames Verständnis von Auftraggeber und Auftragnehmer ist hier für den weiteren Projektverlauf sehr wichtig.

Das Qualitätsziel Barrierefreiheit bzw. Zugänglichkeit benötigt im gesamten Entwicklungsprozess einen Stakeholder, der sich kontinuierlich dafür einsetzt, dass das Thema auch bei Zielkonflikten mit anderen Anforderungen nicht vernachlässigt wird. Sonst besteht immer die Gefahr, dass es zum Beispiel zugunsten von Entwicklungsgeschwindigkeit, Kosteneinsparungen oder gestalterischen Anforderungen zurückgestellt wird. Bei uns nimmt diese Rolle mit Herrn Mengele ein erfahrener Frontend-Entwickler ein, der schon bei der Konzeption, dann bei der Umsetzung und schließlich auch bei der Qualitätssicherung darauf achtet, dass Barrierefreiheit im gesamten Software-Entwicklungszyklus berücksichtigt wird.

Ich sehe meine Rolle deswegen auch eher als Coach und Moderator, der zwischen den Stakeholdern vermitteln muss. Es ist aber oft nicht leicht, hier Experte zu sein, weil man häufig als Spielverderber wahrgenommen wird. Meist ist alles lösbar, aber es müssen eben sehr oft Kompromisse geschlossen werden.

Dazu noch ein Expertentipp, den ich grundsätzlich noch vor dem eigentlichen Projektbeginn einbringe: Barrierefreiheit sollte von Anfang an in alle Überlegungen mit eingebracht werden. Sie spielt zwar vor allem im sogenannten Frontend, also auf der Bedienoberfläche, eine Rolle. Entscheidungen, die für die Oberfläche getroffen werden, stellen erfahrungsgemäß meist überraschende Anforderungen an das Backend (die eigentliche Programmlogik). Überlegungen, die also erst später oder gar nicht getroffen werden, führen oft dazu, dass ganze Teile der Software ersetzt oder im schlimmsten Fall neu programmiert werden müssen, wenn einem die Probleme zu spät oder gar nicht bewusst werden.

Florian Leinberger: Oft werden leider auch Tests mit den betroffenen Personen vernachlässigt. Dabei sind diese besonders wichtig, um wirklich praxistaugliche Lösungen zu schaffen und um das Thema für das Entwicklungsteam weniger abstrakt und besser greifbar zu machen. Für betroffene Menschen sind Software-Barrieren ein echtes Problem. Papiere mit abstrakten Checklisten sind dagegen geduldig.

Was bedeutet strenge Barrierefreiheit aus wirtschaftlicher Sicht für die Entwicklung? Wird eine barrierefreie Anwendung automatisch teurer als eine mit weniger strengen Vorgaben.

Florian Leinberger: Diese Frage hören wir häufig. Barrierefreiheit kommt natürlich nicht zum Nulltarif, soviel ist klar. Genauso wenig wie beispielsweise Sicherheit, Datenschutz, Ausfallsicherheit oder andere Qualitätsziele. Natürlich ist der Ressourcenbedarf dabei höher, wenn man dieses vielschichtige und komplexe Thema ernst nimmt und nicht nur eine oberflächliche, pro forma-Barrierefreiheit anstrebt. Wichtig ist es, die Zugänglichkeit schon bei der Konzeption von Features zu berücksichtigen. Wenn man versucht, eine nicht barrierefreie Funktion erst nachträglich auszubessern, kann das recht teuer werden.

Wir haben in den mehr als drei Jahren, in denen wir nun an dem Projekt arbeiten, festgestellt, dass eigentlich alle Überlegungen hinsichtlich der Barrierefreiheit immer auch für alle Nutzer einen Vorteil hatten. Die allgemeine Benutzerfreundlichkeit hat davon sehr profitiert und ist spürbar, wenn auch nicht sofort als Resultat der Barrierefreiheit wahrnehmbar. Das ist eben das Problem: Man macht Verbesserungen und der Nutzer denkt „Oh cool, dass ich die Schrift einfach so im Browser vergrößern kann.“ Dass das aber eine architektonische Entscheidung ist, die mit viel Schweiß und Herzblut verbunden war, kann man dem Ergebnis nicht direkt entnehmen.

Letztlich muss man die Zugänglichkeit der Software aber als „Return on Investment“ betrachten. Eine offene Gesellschaft wie in Deutschland muss sich diesen vermeintlichen „Luxus“ leisten, denn er ist ein Menschenrecht. Und nebenbei erweitert man mit der Barrierefreiheit seiner Produkte die Marktreichweite, wenn damit alle Menschen zurechtkommen können. Die Amerikaner sagen „Ability is always temporary“, übersetzt vielleicht „Fähigkeit ist immer vorübergehend“. Schon morgen kann man wegen eines Unfalls die Maus nicht mehr bedienen oder verliert aufgrund von Krankheit sein Augenlicht. Am Ende profitieren wir alle davon, wenn Software immer für alle zugänglich ist. Das ist für mich eine Mindestanforderung.

Gibt es Beispiele mit Aha-Effekt, an denen man erklären kann, wie sehr die Tücke auch hier oft im Detail steckt?

Martin Mengele: Da gibt es mehrere Beispiele, die natürlich immer sehr technisch sind. Vielleicht als Beispiel Telefonnummern. Wenn man diese als Link auszeichnet, kann man durch Klicken zum Beispiel auf einem Smartphone direkt telefonieren. Wenn aber ein Screenreader diese vorlesen soll, kommt es oft zu Problemen. Die Nummer +49 123 4567890 wird oft so vorgelesen: „plus vier neun, eins zwei drei, vier Millionen fünfhundertsiebenundsechzigtausend achthundertneunzig“. Screenreader-Nutzer kommen damit wohl irgendwie mehr schlecht als recht klar. Es ist aber bislang noch nicht einheitlich zu steuern, dass ein Screenreader das als Telefonnummer erkennt und die Zahlen einzeln vorliest.

Oder wenn man zur Hervorhebung Großbuchstaben einsetzt, also zum Beispiel bei Fehlermeldung: „WARNUNG! Wenn Sie das Fenster schließen, gehen Ihre Daten verloren!“, dann wird je nach Einstellung im Screenreader der Begriff „Warnung“ buchstabiert vorgelesen. Damit das aber nicht passiert, könnte man den Begriff für Screenreader unsichtbar machen und für diese stattdessen den „normal“ geschriebenen Begriff hinterlegen. Das würde zwar funktionieren, schafft aber eine „Doppelwelt“ mit versteckten Inhalten, die schwieriger zu testen sind, weil sie sehenden Benutzern verborgen bleiben und Fehler somit nicht auffallen würden.

Kann man die erreichte Barrierefreiheit dann quantitativ messen und gibt es ein Qualitätssiegel?

Martin Mengele: Es gab schon Bestrebungen, das abzubilden, ja. Die Initiative „Barrierefrei informieren und kommunizieren (BIK)“ hatte bereits Anfang der 2000er Jahre den sogenannten BITV-Test eingeführt, der die Konformität von Webseiten hinsichtlich der BITV prüfen sollte. Damals konnte man zwischen 0 und 100 Punkten erreichen, 90 galt als „gut zugänglich“ und die getesteten Seiten wurden auch in einer Liste öffentlich geführt. Man durfte dann auch eine Art Siegel-Grafik auf seiner Seite führen, wenn man den Test erfolgreich bestanden hatte. Sowas wie ein TÜV-Stempel für Barrierefreiheit vielleicht (lacht). Das war sehr „en vogue“ in der öffentlichen Verwaltung und man musste Projekte oft mit diesem Test „qualitätssichern“ lassen.

Den BITV-Test gibt es immer noch, jedoch meines Wissens ohne Punktesystem und Siegel. Das liegt vor allem daran, dass Barrierefreiheit kein Zustand, sondern ein Prozess ist. Webseiten oder Software sind ja meist nicht statisch, sondern der Veränderung unterworfen. Sie enthalten immer Fehler oder eben auch Barrieren. So ein Test kann nur eine Momentaufnahme darstellen. Da wird ja auch meist bei Web-Applikationen oder Webseiten nicht die gesamte Seite geprüft, sondern nur ausgewählte Seiten. Barrieren kann es aber überall auf der Seite geben mit jeder Interaktion, die dort stattfindet.

In einem Siegel sehe ich persönlich keinen Sinn. Das hat nur plakativen Wert ohne die eigentliche Aussage, die es bezweckt. Das beste Qualitätssiegel ist für mich ein positives Nutzerfeedback. Wenn zum Beispiel die Testperson in einem Usability-Test mit ihrem Screenreader das Portal ohne Mühe bedienen kann und dann bei bestimmen kleinen Details, die du eingebaut hast, die gute Bedienbarkeit lobt, dann ist das viel wertvoller und hat mehr Aussagekraft.

Wenn nun das Portal barrierefrei ist, wie kann man die Nutzer unterstützen, dass auch die dort eingestellten Inhalte barrierefrei sind?

Florian Leinberger: Dafür gibt es im Wesentlichen zwei sich ergänzende Ansätze: Wirklich barrierefreie Inhalte entstehen nur dann, wenn die Autoren für das Thema sensibilisiert sind und selbst darauf achten, indem sie zum Beispiel allgemein verständliche Formulierungen wählen oder keine Tabellen für Layoutzwecke nutzen.

Zum anderen können Redaktionstools die Anwender technisch dabei unterstützen, möglichst zugängliche Inhalte zu produzieren. So kann beim Einstellen von Bildern ein alternativer Beschreibungstext erzwungen werden oder es kann geprüft werden, ob Tabellen oder Überschriften-Hierarchien strukturell korrekt aufgebaut sind. Zumindest ohne den Einsatz von künstlicher Intelligenz können diese technischen Hilfsmittel durch unwillige Anwender aber oft relativ einfach umgangen oder ausgetrickst werden. Daher ist eigentlich nur die Kombination beider Ansätze erfolgsversprechend: Sensibilisierung der Anwender bei gleichzeitiger technischer Unterstützung.

Martin Mengele: Ergänzend dazu möchte ich mich an dieser Stelle noch einmal wiederholen und darauf hinweisen, dass Barrierefreiheit ein Teamsport ist (lacht).

Daher ist es aus meiner Sicht extrem wichtig, dass man die Anwender gut schult. Wir bilden ja mit unserer Applikation ein Social Intranet ab, sprich: Jeder kann Sender und Empfänger sein. Jeder soll wie ein Redakteur Inhalte erstellen können und mit den anderen Portalnutzern in Kontakt treten können. In diesem Umfeld ist es natürlich besonders schwierig, die Anwender zu schulen und eigentlich nicht gewollt, weil man ja erreichen will, dass von Anfang an alle mitmachen können. Wir bieten natürlich trotzdem auch Schulungen an. Aber in diesem speziellen Fall verhindern wir durch bestimmte Vorgaben oder Abläufe in der Software, dass schon beim Erstellen der Inhalte Barrieren entstehen können.

Zum Abschluss noch ein Tipp – was ist der typische Fehler, der rund um die Barrierefreiheit von webbasierten Anwendungen gemacht wird und wie kann man ihn vermeiden?

Martin Mengele: Das schwierige ist, dass zu diesem Thema viel gefährliches Halbwissen kursiert, dem die Verantwortlichen oder Entwickler oft anheimfallen. Ein Mythos, der immer noch im Umlauf ist, lautet: „JavaScript ist eine Barriere!“ oder „Um barrierefrei sein zu können, muss eine Webapplikation auch ohne Javascript funktionieren!“. Genau das Gegenteil ist der Fall. Echte Barrierefreiheit ist ohne JavaScript gar nicht möglich. Es muss jedoch korrekt eingesetzt werden, sonst können daraus schnell Barrieren oder sogar im schlimmsten Fall Fehler entstehen, die die ganze Anwendung „crashen“ lassen.

Florian Leinberger: Ein typischer Fehler ist es, sich auf das alleinige pro-forma-Abhaken von Anforderungskatalogen zur Barrierefreiheit zu beschränken und nicht mit betroffenen Personen in Dialog zu treten, um für diese Nutzergruppen wirklich praxistaugliche Lösungen zu schaffen. Richtig teuer kann es dann werden, wenn man das Thema Zugänglichkeit nicht schon bei der Konzeption von Features berücksichtigt, sondern eine Anwendung nach negativem Prüfergebnis erst nachträglich barrierefrei machen muss.

Herr Leinberger, Herr Mengele, vielen Dank für dieses Gespräch.