Barrierefreie Software

Hindernisse überwinden

| Autor / Redakteur: Harald Griober* / Susanne Ehneß

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.

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.

Essenzielle Funktionen versus Nice-to-have

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. Assis­tive Technologien wie Screenreader können mit solchen Benutzeroberflächen nur schwer umgehen. Bei Business-Software gilt daher: Weniger ist mehr.

Zugunsten der Nutzerfreundlichkeit sollte mit bunten Bedien­elementen sparsam umgegangen ­werden. Eine einfach zu erschließende, klar strukturierte Benutzeroberfläche, auch wenn sie anfangs langweilig erscheint, ist mit hoher Wahrscheinlichkeit barriere­frei – 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 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, Grundlagen zu schaffen. Ein klarer­ und detailliert formulierter Anforderungskatalog spart am Ende ­viele Iterationen und Testzyklen.

Auf der nächsten Seite: Interdisziplinäre Teams in der Entwicklung & rechtliche Grundlagen.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45729087 / System & Services)