Barrierefreie Software

Barrierefrei: Dieser Begriff kommt ursprünglich aus dem Bauwesen. Einem Benutzer sollen keine Barrieren in den Weg gelegt werden, welcher Art auch immer. An vielen Stellen im öffentlichen Raum begegnen uns Maßnahmen zur Barrierefreiheit. Rampen erleichtern Rollstuhlfahrern das Überwinden von Höhenunterschieden, Tonsignale an Ampeln "übersetzen" Blinden und Sehbehinderten das Signal zum Überqueren der Straße.

Was bedeutet barrierefrei in puncto Software?

Analog dazu soll es barrierefreie Software jedem Mitarbeiter eines Unternehmens oder einer Behörde ermöglichen, dieselbe Arbeit machen zu können, etwa in einem Callcenter Anrufe entgegennehmen und Geschäftsvorfälle lösen. Dabei spielt es zunächst keine Rolle, um welche Barriere es sich handelt. Typische Barrieren entstehen durch körperliche Einschränkungen aufgrund einer Behinderung, etwa den fehlenden Seh- oder Hörsinn oder motorische Einschränkungen.

Damit ist nicht mit wenigen Worten oder Sätzen zu definieren, was eine barrierefreie Software können muss. Wann ermöglicht es eine Software allen Mitarbeitern, die gleiche Arbeit machen zu können? Wie kann die jeweilige Einschränkung durch die Software kompensiert werden?

Normen wie die ISO 9241 für die "Ergonomie der Mensch-System-Interaktion", die "Web Content Accessibility Guidelines (WCAG)" des World Wide Web Consortiums und die "Barrierefreie Informationstechnik Verordnung (BITV 2.0)" geben Kriterien an die Hand, wie barrierefreie Software sein sollte.

Darunter finden sich zum Beispiel folgende Kriterien:

• Trennung von Text und Layout, damit beispielsweise Text von Screenreadern ausgelesen und auf eine Braille-Zeile ausgegeben werden kann. Ein Braille-Zeile ist eine Art Tastatur, die Text in Blindenschrift widergibt.

• Für jeden Nicht-Text-Inhalt Alternativen in Textform anbieten. Am bekanntesten sind wohl Alt-Tags für Bilder auf Webseiten.

• Logischer, hierarchischer Aufbau der Software, d.h. Inhalte sind so aufzubereiten, dass sie ohne Informationsverlust in welcher Art auch immer ausgelesen werden können.

• Vorsichtiger Umgang mit Farbe: Sie darf nicht das einzige Mittel sein, um Informationen zu übermitteln oder eine Reaktion zu veranlassen, etwa die Farbe Rot bei Buttons und Warnhinweisen.

• Tabulator-Steuerung: Alle Funktionen sollen über eine Tastatur gesteuert werden können. Gerade in der Bewegung eingeschränkte Menschen tun sich schwer mit der Maus.

• Offenheit in Bezug auf Betriebssysteme und Endgeräte, um etwa Screenreader, Vorlesehilfen und andere assistive Technologien anbinden zu können.

• Offenheit in Bezug auf die Skalierung und Darstellung, um z.B. Vergrößerungen, Invertierungen oder besonders kontrastreiche Darstellungen zu ermöglichen

Open from Scratch

Diese Kriterien erscheinen logisch, definieren sie doch moderne Software-Architekturen mit einem "sauberen", universalen Code. Gute Software-Applikationen sollen alle Funktionen für alle zur Verfügung stellen. Die Praxis sieht aber anders aus. Häufig ist der Code nicht barrierefrei. Screenreader, die beispielsweise eine Oberfläche über Sprache ausgeben, erhalten keinen Zugang zu den Informationen oder noch schlimmer: Informationen werden fehler- oder lückenhaft ausgelesen.

Das ist zum Beispiel bei Web-Browsern der Fall, die in Thin-Client-Architekturen häufig als Benutzeroberfläche für Applikationen verwendet werden. So lässt sich zum Beispiel die Baumnavigation mit den gängigen Web-Browsern gut visuell darstellen, sie kann aber mithilfe eines Screenreaders manchmal nicht fehlerfrei ausgelesen werden. Genau das darf bei barrierefreien Anwendungsszenarien nicht passieren. Ein Blinder muss sich auf das verlassen, was er hört.

Achten Sie bei der Anschaffung von Software auf einen hohen Barrierefreiheitsgrad. Wie so häufig steckt hier der Teufel im Detail, soll heißen: in der Code-Ebene.

Essenzielle Funktionen versus "nice to have"

Auch in puncto Benutzeroberfläche machen sich die Hersteller nicht immer Gedanken, ob Funktionen in ihrer Software für eingeschränkte Menschen gut oder überhaupt bedienbar sind. Moderne Software ist, analog zum Trend im Netz, sehr visuell. Applikationen arbeiten mit Bildern wie Tortengrafiken oder Kartenausschnitten, farblichen Elementen wie Ausgrauungen oder Rot-Grün-Gegensätzen, schwebenden Menüs, animierten Elementen wie Blink-Effekten oder Timern, Drag and Drop oder Overlays.

All diese Elemente sind häufig nicht, wie Tabellen, logisch, sequenziell oder hierarchisch angeordnet. "Assistive" Technologien wie Screenreader können mit solchen Benutzeroberflächen nur schwierig umgehen.

Bei Business-Software gilt daher: Weniger ist mehr. Zugunsten der Nutzerfreundlichkeit sollte mit bunten Bedienelementen sparsam umgegangen werden. Eine einfach zu erschließende, klar strukturierte Benutzeroberfläche, auch wenn sie anfangs langweilig erscheint, ist mit hoher Wahrscheinlichkeit barrierefrei - und letzten Endes auch für andere Nutzer ohne Einschränkungen meist effektiver zu bedienen.

Grundlage schaffen

In vielen unserer Projekte für barrierefreie Software-Anwendungen stoßen wir auf nur sehr wenige Vorgaben im Anforderungskatalog. Das ist einerseits der häufig noch fehlenden Erfahrung mit Barrierefrei-Implementierungen geschuldet, andererseits fehlt es an Wissen in der technologischen Tiefe. Die Fragen lauten: Was muss umgesetzt werden? Was kann umgesetzt werden? Und wie?

Nehmen wir das Beispiel eines Callcenters: Der Prozess 'Anruf - Annahme - Bearbeitung - Auflegen - Nachbearbeitung' soll für blinde Mitarbeiter und Mitarbeiter mit motorischen Einschränkungen barrierefrei gestaltet werden.

Für die blinden Nutzer muss die komplette Mausbedienung in Shortcuts, Tabulatorsteuerung und Ein- und Ausgabe auf die Braille-Tastatur übertragen werden. Eine Alternative zur Maussteuerung hilft auch motorisch eingeschränkten Anwendern, weil sie mit Tabulatoren und Shortcuts oft schneller sind als mit der Maus. Für eingeschränkt Sehende braucht es außerdem Möglichkeiten zur extremen Vergrößerung und starke Kontraste. Ausgrauungen oder farbliche Elemente wie Buttons und Unterlegungen müssen ausgeschaltet werden.

Dann gilt es zu überlegen, wie der Prozess und Teilprozesse abgebildet werden. Wie soll beispielsweise der Blinde über einen ankommenden Anruf benachrichtigt werden und wie nimmt er ihn an? Wie dokumentieren motorisch eingeschränkte Nutzer, die nur sehr langsam oder eingeschränkt tippen können, Geschäftsvorfälle? Wie werden zusätzliche Dokumente wie Gesprächsleitfäden zugänglich gemacht?

Zum Schluss müssen die "übersetzten" Funktionen in Skillsets, Anwenderprofile, die bestimmte Fähigkeiten und Fachwissen voraussetzen, hinterlegt werden.

Ein ziemlich komplexer Prozess also. Deshalb gilt es gleich zu Anfang, Grundlage zu schaffen. Ein klarer und detailliert formulierter Anforderungskatalog spart am Ende viele Iterationen und Testzyklen.

Interdisziplinäre Teams

Gemischte Teams aus IT-Leuten, Entwicklern, Fachverantwortlichen und Anwendern haben sich bei der Entwicklung von Business-Applikationen bewährt. Auch in Barrierefrei-Projekten kann es sehr sinnvoll sein, die eigentlichen Nutzer, eingeschränkt und nicht, in den Entwicklungsprozess einzubeziehen. Gerade behinderte Benutzer wissen sehr gut, wie man Herausforderungen im Alltag löst und können bei der "Übersetzung" von Funktionen und Teilprozessen sicher viele nützliche Ideen einbringen. Auch in der Testphase sollten Sie die User konsequent einbeziehen.

Erfahrene Partner

Scheuen Sie sich nicht davor, Experten hinzuzuziehen, wenn Sie nicht über detaillierte technologische Kenntnisse oder Erfahrung mit barrierefreier Software verfügen. Ein guter Partner bringt neben Erfahrung viel Einfühlungsvermögen, Ideen und technologisches Können ins Projekt ein. Das haben bisher nur wenige. Außerdem vermittelt Ihnen ein seriöser Partner Kontakt zu den Verantwortlichen in Referenzprojekten. Sprechen Sie mit den Kollegen und lernen Sie von ihren Herausforderungen. Denn selbst, wenn alle Voraussetzungen gut sind, dauert es viele Tests und Iterationen, bis eine barrierefreie Bedienung steht.