Screenreadertauglich heißt nicht barrierefrei
Wann ist Software eigentlich wirklich barrierefrei?

Bei der Entwicklung von Software wird immer öfter ein Screenreader als Indikator für den Grad der Barrierefreiheit genutzt. So wünschenswert es auch ist, dass den Bedürfnissen blinder ComputernutzerInnen auf diesem Wege Rechnung getragen wird, es ist leider nur dir halbe Miete. Denn was für Blinde geeignet ist, muss für Sehbehinderte noch lange nicht gut sein. Blinde Menschen brauchen weder gute Kontraste, noch große Schriften. Und ob der Fokus hervorgehoben dargestellt wird oder nicht, ist für diese Nutzergruppe ebenfalls gleichgültig. Hauptsache, Braillezeile und Sprachausgabe spucken etwas aus.

Wann ist Software eigentlich barrierefrei?

Bei mir mehren sich in letzter Zeit die Anfragen von Kunden, die wissen wollen, ob das Programm-Paket, das sie gerade für viel Geld gekauft haben, überhaupt barrierefrei ist. Auslöser sind in diesen Fällen oft Mitarbeiter, die immer weniger sehen oder erblindet sind, aber auch neu hinzugekommene Mitarbeiter mit Behinderungen. Diese klagen dann in der Regel über Schwierigkeiten bei der Handhabung der Software. Dabei geht es meist nicht um irgendwelche Kleinigkeiten, sondern um grundlegende Funktionen, die die tägliche Arbeit erschweren oder sogar, trotz vorhandener Qualifikation, unmöglich machen. Solch ein Zustand verunsichert verständlicherweise. Es geht dabei doch um nichts Geringeres als die eigene Existenz. „Kann ich den Job unter diesen Umständen noch ausüben?“, „Wie komme ich damit klar, wenn ich in eine andere Abteilung versetzt werde?“ – diese und andere Fragen machen klar, dass wir noch lange nicht an dem Punkt angekommen sind, an dem Behinderung kein Hinderungsgrund für die Einstellung ist. Ganz im Gegenteil. Derzeit zeichnet sich ein Trend zu neuen Speziallösungen ab, welcher auf Seiten der Software-Anbieter bereits gewonnene Erkenntnisse zur barrierefreien Gestaltung plötzlich einfach über Bord zu werfen droht und nach einem Update eine Software präsentiert, die für Menschen mit Behinderungen vollkommen unbrauchbar ist. Übrigens oft ganz im Gegensatz zu Aussagen im Angebot, auf welches sich Käufer solcher Software natürlich stützen. So etwas geschieht nicht mit böser Absicht, doch drängt sich mir der Verdacht auf, dass jede Programmierer-Generation zumindest in Teilbereichen das eine oder andere Rad neu erfinden möchte. Vielleicht wurde in solchen Fällen auch einfach nur schlecht dokumentiert oder kommuniziert. Wie auch immer: Barrierefreie Software ist immer noch die Ausnahme, nicht die Regel.

Das Ursache-Wirkungs-Problem der barrierefreien Nutzung

Dabei bieten moderne Programmier-Umgebungen eine Vielzahl von Möglichkeiten, auf die Bedürfnisse von Menschen mit Behinderungen einzugehen. Das zeigt zum Beispiel sehr anschaulich der Blog und die Webseite des Programmierers Markus Lemcke (Link zum Blog: http://www.marlem-software.de/marlemblog/). Um bereits während der Programmierung feststellen zu können, ob man sich hinsichtlich der Barrierefreiheit auf dem richtigen Weg befindet, nutzen die Motivierteren gerne Screenreader, die per Sprachausgabe alle textlichen Informationen am Bildschirm wiedergeben. Und genau diese Praxis führt oft zu einem Missverständnis: Plötzlich glaubt man, dass ein Programm barrierefrei ist, wenn es mit einem Screenreader genutzt werden kann. Das führt sogar so weit, dass man Anpassungen am Screenreader vornimmt, damit auch unzugänglich programmierte Bestandteile der Software genutzt werden können. Später behauptet man dann, dass die Anwendung auf Grund dieser Anpassungen barrierefrei ist. Es ist zwar wunderbar, dass moderne Screenreader solche Nachteile ausgleichen können, aber mit Barrierefreiheit hat das nichts zu tun. Sonst könnte man auch behaupten, jede Kleidung wäre wasserdicht, sobald man eine Regenjacke anziehen kann. „Wenn ein Screenreader alles richtig vorliest, dann ist meine Software also nicht unbedingt barrierefrei?“ – Ganz recht!. Die Berücksichtigung der Bedürfnisse von blinden Menschen schließt ja noch längst nicht alle Arten von möglicher Behinderung und damit Nutzungsanforderungen mit ein.

Konzepte für Alle

Wenn ohne zusätzliche Anpassungen ein Screenreader alles richtig vorliest oder per Braillezeile ausgibt, dann ist mit Sicherheit schon viel erreicht. Doch sind damit auch alle Anforderungen von Menschen mit einem gewissen Rest-Sehvermögen erfüllt? Was ist mit Menschen, die ausschließlich mit der Tastatur arbeiten, aber auf erläuternde Tooltipps angewiesen sind? Was mit denen, die nur mit der Maus arbeiten können, weil sie weder Hände noch Füße für die Arbeit am PC nutzen können? Was ist für Menschen mit Hörbehinderungen zu beachten? Wie formuliere ich richtig? Wann brauche ich erläuternde Gebärdensprach-Videos? Dann gibt es noch Diejenigen, die vielleicht nur etwas weniger sehen als früher, aber noch keine Vergrößerungs-Software benötigen, weil es vollkommen ausreichen würde, wenn die Bildschirm-Schriften ein wenig größer wären. Die Liste könnte noch um viele Beispiele fortgesetzt werden, was mehr und mehr den Bedarf nach einer gewissen abstrakten Ebene verdeutlicht, welche nach Möglichkeit die Bedürfnisse Aller berücksichtigt. Die Schaffung einer solchen Abstraktions-Ebene ist kein leichtes Unterfangen. Das Beispiel der aktuellen Web-Content-Accessibility-Guidelines (WCAG 2.0) zeigt dies sehr deutlich. Obwohl die vier Prinzipien „Wahrnehmbarkeit“, „Bedienbarkeit“, „Verständlichkeit“ und „Robustheit“ bereits seit ca. 2003 bekannt waren, dauerte es noch fünf weitere Jahre, bis diesen Prinzipien einvernehmlich allgemeingültige und technik-unabhängige Anforderungen für ein barrierefreies Web untergeordnet werden konnten. Zum besseren Verständnis der vier Prinzipien hier eine kurze Erläuterung:

  • Wahrnehmbar (Perceivable) zum Beispiel durch Textalternativen für Bilder, Untertitel für Audio, Anpassbarkeit der Darstellung und Farbkontraste
  • Bedienbar (Operable) Maus- und Tastaturbedienung, Farbkontraste, Zeitbegrenzungen bei Eingaben, Navigierbarkeit
  • Verständlich (Understandable) Lesbarkeit, Vorhersagbarkeit, Hilfen bei Fehlern und bei der Eingabe
  • Robust (Robust) durch Kompatibilität mit Browsern und mit assistierenden Technologien

Was hier für das Web geschaffen wurde, ist in weiten Bereichen auch auf Software übertragbar. Man kann beispielsweise im Bereich der Robustheit sagen, dass eine Kompatibilität mit unterschiedlichen Betriebssystemen möglich sein muss oder dass man nach einem Update nicht mit vollkommen neuen Bedienkonzepten oder Tastenkombinationen konfrontiert werden darf (wie z.B. bei Microsoft Office).

Gibt es überhaupt barrierefreie Software?

Von Microsoft Office wird ja gerne gesagt, dass es barrierefrei sei. Das stimmt so leider nicht. Einerseits gibt es da dieses Manko im Bereich der Robustheit, andererseits liefert der Hersteller des Screenreaders Jaws seine Software mit werksseitig installierten Scripten speziell für MS-Office aus, so dass man aus dieser Perspektive überhaupt nicht sagen kann, in welchem Maße das Programmpaket barrierefrei ist. Dies gilt für eine Vielzahl weiterer Programme, die auf der Internetseite des Herstellers (www.freedomscientific.de) zu finden sind. Versucht man z.B., in MS-Office unter Windows 7 die Systemschriften so einzustellen, dass die Menü-Schriften größer dargestellt werden, dann muss man dafür den System-Typ „Markierte Elemente“ neu definieren. Der Dialog dafür findet sich versteckt im Bereich der Farbeinstellungen für das ausgewählte Aero-Design. Hier werden sowohl auf der Seite des Betriebssystems wie auch seitens der Software eine ganze Reihe von Anforderungen missachtet. Viele der Options-Dialoge bieten überhaupt keine Einstellmöglichkeit. Eigentlich sollte man ja erwarten, dass es irgendwo einen leicht aufzufindenen Dialog gibt, der die Möglichkeit bietet, die Größe der System-Schriften zu definieren. Doch weder Microsoft noch Apple bieten hier befriedigende Lösungen. Sie bieten stattdessen im System eingebaute Vergrößerungs- oder Sprachausgabe-Funktionen, was uns wieder zu dem Vergleich mit der Kleidung und der Regenjacke führt. In diesem Punkt bietet das Linux-Betriebssystem übrigens gute Lösungen an. Ob Gnome, Unity, KDE oder XFCE, alle vier Desktop-Umgebungen bieten einfache und leicht zu findende Möglichkeiten der Systemschrift-Vergrößerung. Was allerdings die Möglichkeiten der Nutzung von Screenreadern und Vergrößerungs-Software betrifft, gibt es zwar eine Reihe von positiven Ansätzen, jedoch keine wirklich professionellen Lösungen wie unter Windows oder OS X. Für OS X gibt es die kommerzielle Software Tinker-Tools, mit welcher sich eine Reihe von zusätzlichen Systemeinstellungen vornehmen lassen. Leider werden von den aktuellen (Lion) Versionen des Betriebssystems die individuellen Einstellungen der Systemschrift nicht mehr übernommen. Apple verweist darauf, dass innerhalb vieler Anwendungen die Systemschrift individuell angepasst werden kann. Dies trifft beispielsweise auf die Mozilla Produkte Firefox und Thunderbird zu.

Wie kann Software auf Zugänglichkeit getestet werden?

Um also den Anforderungen aller drei Betriebssystem-Umgebungen hinsichtlich der barrierefreien Gestaltung zu genügen. muss weit mehr berücksichtigt werden als nur die Screenreader-Tauglichkeit. Im Groben kann man die Anforderungen so zusammenfassen:

  • Unterstützung der individuellen Anpassbarkeit der Größe, Farbe sowie der Schriftart von Systemschriften,
  • Unterstützung unterschiedlicher Eingabemöglichkeiten (ausschließliche Tastaturbedieung, ausschließliche Mausbedienung, Touch-Bedienung, …)
  • Übernahme der individuellen Einstellung der Vorder- und Hintergrund-Farben des Betriebssystems (… und damit auch Unterstützung eines Kontrastmodus).
  • Barrierefreie Hilfe-Funktion einschließlich der Dokumentation aller Tastaturkommandos.
  • Deutlicher Tastatur-Fokus,
  • Text-Alternativen.

Zur strukturierten Dokumentation von Software-Tests nehme ich seit vielen Jahren schon die IBM-Software-Accessibility-Checliste zu Hilfe. Angenehmer wäre es mir, wenn es endlich einen mit den WCAG vergleichbaren Standard des W3C geben würde. Dieser lässt auf sich warten und es bleibt zu hoffen, dass das EU-Mandat 376 in absehbarer Zeit eine Basis bietet, auf die sich im Rahmen von Prüfungen Bezug nehmen lässt. Bis es so weit ist, gleicht das Testen von Software auf Barrierefreiheit in weiten Bereichen Usability-Tests, mit welchen die Gebrauchstauglichkeit von Software ermittelt wird. Allerdings sind z.B. Heuristiken, für welche im Idealfall eine Vielzahl von Testpersonen zur Verfügung stehen müssten, für Zugänglichkeits-Tests nicht notwendig. Die Kunst liegt letztlich darin, ein geeignetes Szenario zu finden, welches die Nutzung so vieler Bereiche der Software notwendig macht, dass nahezu alle vorhandenen Menüs, Dialoge, Symbole, Tastenkombinationen, Eingabemöglichkeiten etc. in Erscheinung treten. Spielt man nun dieses Szenario für jede der Anforderungen z.B. der IBM-Checkliste durch, können eine Vielzahl von Barrieren gefunden werden, die im Normalfall unentdeckt blieben. Ein Gutachten auf dieser Basis bietet eine brauchbare Unterstützung bei der barrierefreien Überarbeitung von Software. Doch auch hier gilt: Barrierefreiheit ist ein iterativer Prozess. Die Marke von 100% kann praktisch nie erreicht werden. Das mag ärgerlich erscheinen, jedoch empfehle ich, das gelassen zu sehen. Denn der beste Weg hin zu einer perfekten Software ist immer noch der konstruktive und strukturiert organisierte Dialog zwischen Kunde und Hersteller sowie dessen Bereitschaft, auf die Bedürfnisse von Kunden einzugehen.

Detlef Girke, 02.04.2013