Barrierefreie Software
Was Unternehmen und Behörden beachten sollten
Fortsetzung des Artikels von Teil 1
Alle Funktionen für alle Nutzer
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.
Bei der Anschaffung von Software sollte man auf einen hohen Barrierefreiheitsgrad achten. 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?
Zum Beispiel Callcenter: 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.
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.
Harald Griober ist bei dem Hamburger Systemhaus IP Dynamics zuständig für die Qualitätssicherung
- Was Unternehmen und Behörden beachten sollten
- Alle Funktionen für alle Nutzer
Lesen Sie mehr zum Thema
