Abbildung 4: Blinde ertasten die Ausgaben des Computers auf einer Braillezeile. Dazu sind ein Braille-Treiber sowie ein Screenreader wie Gnopernicus erforderlich.

Wie fast jedermann arbeiten auch Sehbehinderte und Blinde am Computer. In einem Wochenend-Experiment in Berlin haben Usability-Fachleute und Betroffene untersucht, was Open-Source-Software für die barrierefreie Computerbenutzung in der Praxis taugt – und wie sie sich verbessern lässt.

Abbildung 1: Usability-Expertin Ellen Reitmayr und der sehbehinderte Linux-Benutzer Lars Stetten testen Farbschemata und Vergrößerungssoftware für KDE.

Als Sebastian Andres aus Marburg mit Suse 8.0 in Linux einstieg, suchte er wie viele andere Anwender Unterstützung bei der lokalen Linux-Usergroup. Dort half ihm unter anderem Lars Stetten weiter. Der blinde Sebastian und der sehbehinderte Lars haben besondere Anforderungen an ein Computersystem – und sie wissen, dass geeignete Software und Hilfe bei der Installtion nicht leicht zu finden sind. Daher gründeten die beiden Informatikstudenten eine Initiative, die behinderten Linux-Benutzern Unterstützung anbietet und daneben Öffentlichkeitsarbeit zum Thema Barrierefreiheit (Accessibility) betreibt.

Auf einer Grillparty an der Lahn wurde 2004 die Idee geboren, mittlerweile ist das Team von Linaccess [1] auf zahlreichen Linux-Veranstaltungen vertreten. Doch viele Fragen der Besucher nach dem Entwicklungsstand und der Tauglichkeit freier Hilfsmittelsoftware konnten sie nicht konkret beantworten. Ein ausführlicher Test aktueller Programme stand bereits auf ihrer Wunschliste, als sie bei Vorträgen Ellen Reitmayr vom Projekt Open Usability [2] kennen lernten und Kontakt zu Joko Keuschnig vom Kompetenzzentrum “Barrierefrei kommunizieren” [3] des Jugendfreizeit- und Bildungsvereins e.V. fanden.

Wochenend-Workshop

Der Verein stellte seine Berliner Räume und Hardware zur Verfügung, Usability-Expertin Ellen Reitmayr übernahm die Dokumentation der Ergebnisse. Ende Februar 2006 konnte das “Accessibility meets Usability Weekend” über die Bühne gehen. Drei Sehbehinderte und zwei Blinde aus dem Linaccess-Team testeten Farbschemata für KDE, den Prototyp einer freien Vergrößerungssoftware und außerdem Gnopernicus, die Gnome-Accessibility-Software für Blinde. Derzeit arbeitet Ellen noch an der ausführlichen Dokumentation.

Hoher Kontrast

Sehbehinderte benutzen häufig eine Bildschirmdarstellung mit großen Schriften sowie hohem Kontrast. Dabei kommt weißer Text auf schwarzem Hintergrund zum Einsatz, da diese Benutzer von großen hellen Flächen geblendet werden.Auf dem Wochenend-Workshop testeten Lars Stetten und Christoph Niehaus das Farbschema “High Contrast White Text” für KDE 3.5 unter Kubuntu 5.10. Dieses Schema stellt ausgewählte Elemente nicht wie üblich invers (Abbildung 2a) dar, sondern mit einer gestrichelten Umrandung (Abbildung 2b), um Blendung zu vermeiden.

Abbildung 2a: Das Standard-Schema von KDE stellt ausgewählte Elemente invers dar.

Abbildung 2b: Im Farbschema “High Contrast White Text” dient ein Rahmen zur Hervorhebung.

Um eine vollständige Weiß-auf-schwarz-Darstellung zu erreichen, mussten die Workshop-Teilnehmer noch einige KDE-Elemente manuell umstellen, darunter das Uhren-Applet, Kicker und den Mauszeiger. Den Desktop-Hintergrund färbten sie dunkelblau ein und aktivierten das Accessibility-Stylesheet im Browser Konqueror. Die Icons stammen vom Monochrome-Theme [4] aus dem KDE-Accessibility-Paket, als Größe für Systemschriften verwendeten die Probanden 22 (die KDE-Oberfläche gibt nicht an, ob es sich um Pixel oder Punkte handelt).

Außerdem nutzen sie die Fähigkeit des X-Servers, mit virtuellen Bildschirmauflösungen umzugehen. In der Einstellung von Lars zeigt der am Monitor sichtbare Bildausschnitt (Viewport) nur etwa ein Viertel des gesamten virtuellen Bildschirms (Abbildung 3). Damit erzielt er eine optische Vergrößerung der Bedienelemente. Erreicht er mit der Maus den Rand des sichtbaren Bereichs, verschiebt dieser sich automatisch.

Abbildung 3: Virtuelle Auflösung: Das Display zeigt ein Viertel der gesamten Arbeitsfläche, hier das KDE-Terminal Konsole.

Auf dem so eingestellten System führten die Benutzer eine Reihe von Arbeitsaufträgen aus. Unter anderem besuchten sie eine Website, luden dort ein PDF herunter und betrachteten es mit geeigneter Farbeinstellung in KPDF. Außerdem verfassten sie einen Text im Editor Kate.

Dabei offenbarten sich einige Probleme: Beispielsweise lässt sich der Mauszeiger in KDE im Gegensatz zu den Schriften nicht beliebig groß einstellen. Die Tester verloren beim Arbeiten häufig den Zeiger aus dem Blick und brauchten einige Zeit, um ihn wiederzufinden, indem sie die Maus bewegten. Berührten sie dabei den Rand des Viewport, verloren sie zudem ihre Position in der Anwendung – frustrierend und Zeit raubend.

Nicht okay

Die umfangreichen KDE-Dialogfenster, deren Größe sich in einigen Fällen nicht ändern lässt, sorgten für weitere Schwierigkeiten: In der eingesetzten virtuellen Auflösung sind sie oft nicht vollständig sichtbar, das Bewegen der Fenster bedeutet Zeitverlust und Ablenkung. In zwei Fällen waren die »OK«-Buttons am Fuß des Dialogfensters gar nicht ereichbar und sie reagierten nicht auf den üblichen Tastaturbefehl [Alt]+[O].

Ellen Reitmayr und Tina Trillitzsch von Open Usability beobachteten die Testpersonen bei der Bedienung und befragten sie zu Problemen und ihren sonstigen Arbeitsgewohnheiten. Lars beispielsweise arbeitet täglich mit KDE. Er verwendet das vorgefertigte Farbschema, passt jedoch das Aussehen einiger Bedienelemente und Anwendungen noch manuell an seine Bedürfnisse an. Insbesondere in Konqueror nimmt er einiges Tuning vor, um möglichst viele Websites lesbar zu machen.

Unter der Lupe

Sehbehinderte Windows-Benutzer verwenden keine virtuelle Auflösung, sondern Vergrößerungssoftware. Solche Programme umgehen die Probleme, die der Einsatz von großen Schriften verursacht, da die ursprünglichen Proportionen der Benutzeroberfläche erhalten bleiben. Für das Microsoft-Betriebssystem stehen zwar kostspielige, aber ausgereifte und bedienungsfreundliche Vergrößerungsprogramme zur Verfügung.

Für Linux gab es bisher nichts Vergleichbares, doch Gunnar Schmidt [5] vom KDE-Accessibility-Projekt [6] arbeitet derzeit im Rahmen seiner Informatik-Diplomarbeit an einer Bildschirmlupe für die Desktop-Umgebung. Einen ersten Prototyp konnten Mirko Blinn und Christoph Niehaus testen. Die Software beherrscht bereits mehrere Vergrößerungsgrade, die Anzeige im Fullscreen- oder Fisheye-Modus sowie normale oder invertierte Farbdarstellung.

Im Test bereitete die Verfolgung des Mauscursors den Probanden allerdings große Probleme: Bewegten sie den Zeiger an den Rand des sichtbaren Bereichs, verschob er sich nicht stufenlos, sondern sprang zum nächsten Bildschirmausschnitt. Gleichzeitig setzte der Prototyp den Mauszeiger in die Bildschirmmitte. Beim Arbeiten mit E-Mails verhinderte dieses Verhalten flüssiges Lesen – die Anwender fanden den Anfang der nächsten Zeile nicht.

Als Anregung zeigte Christoph, wie das kommerzielle Programm Textzoom, das er unter Windows benutzt, den angezeigten Ausschnitt steuert. Dort bleibt die Maus stets in der Bildschirmmitte, beim Bewegen verschiebt sich nur die Desktop-Oberfläche darunter. So verliert der Benutzer weder die Maus noch seinen Arbeitsbereich aus dem Blick.

Beim Verfassen von E-Mails konnten die Tester den Entwickler Gunnar Schmidt auf weitere Probleme aufmerksam machen. Klickten die Anwender in Kontact auf »New Mail«, passierte anscheinend nichts. Das Editor-Fenster zum Verfassen der Nachricht hatte sich außerhalb des sichtbaren Bereichs geöffnet.

Das Team schlug vor, die Vergrößerungssoftware solle den Benutzer informieren, dass ein neues Fenster den Fokus verlangt und den angezeigten Ausschnitt stufenweise dorthin verschieben. Beim Schreiben der Mail mussten die Testpersonen den Viewport manuell verschieben, wenn der Text einer Zeile den Rand des Bildausschnitts erreichte – ein bedienungsfreudliches Programm sollte den Tastatureingaben folgen.

Auch zur Weiterentwicklung des invertierten Anzeigemodus gab der Test nützliche Anregungen. Derzeit kehrt die Bildschirmlupe nur den Helligkeitswert um. Bei den E-Mail-Headern in K-Mail führte das zu blauem und rotem Text auf schwarzem Hintergrund, den die Probanden nicht lesen konnten. Ein Algorithmus, der alle Farbkanäle invertiert, könnte dieses Problem lösen.

Software für Blinde

Blinde Benutzer ertasten die Ausgaben des Rechners über ein Gerät, das sie mittels beweglicher Stifte in Blindenschrift ausgibt [7], die so genannte Braillezeile (Abbildung 4). Daneben setzen sie Text-to-Speech-Systeme (TTS) ein, um sich Menüs und Dokumente vorlesen zu lassen. Die Übersetzung sichtbarer Inhalte in Braille oder Sprache übernimmt ein Spezialprogramm, der Screenreader. Das funktioniert nicht nur auf einer reinen Textkonsole, sondern auch bei grafischen Benutzeroberflächen. Für Gnome existiert bereits der freie Screenreader Gnopernicus [8]. Die Bibliothek GTK+ besitzt eine Accessibility-Schnittstelle, über die Gnome-Programme dem Screenreader die benötigten Informationen zur Verfügung stellen können – leider nutzen nicht alle Anwendungsentwickler diese Möglichkeit.

Abbildung 4: Blinde ertasten die Ausgaben des Computers auf einer Braillezeile. Dazu sind ein Braille-Treiber sowie ein Screenreader wie Gnopernicus erforderlich.

Screenreader-Installation

Für den Gnopernicus-Test kam die Distribution Ubuntu Dapper Drake zum Einsatz. Zur Installation von Version 1.0.4 des Screenreaders genügte »apt-get install gnopernicus«. Da die mitgelieferte freie Sprachausgabe Festival [9] über keine deutsche Stimme verfügt, tauschte das Team das Paket gegen die Linux-Version von IBMs kommerzieller Software Viavoice aus. Den Braillezeilen-Treiber von Gnopernicus ersetzten sie durch BRLTTY [10], das eine größere Anzahl von Geräten unterstützt.

Sebastian Andres und Henning Oschwald konnten problemlos per Tastatur und Braille-Ausgabe im Texteditor Gedit arbeiten und eine CD aus dem Filemanager Nautilus heraus brennen. Evolution und der grafische Paketmanager dagegen blieben nicht benutzbar. Außerdem beherrscht die Sprachausgabe keine deutschen Umlaute – statt ä oder ü gab die Computerstimme einen Wust anderer Sonderzeichen von sich. Teilweise blieb sie auch komplett sprachlos. Die blinden Benutzer wussten den Fehler nicht zu deuten und konnten sich nur mit einem Reboot behelfen. Sebastians Fazit: “Man merkt, dass die Entwicklung Fortschritte macht. Für den Alltag oder gar das Berufsleben würde ich das aber noch nicht verwenden.”

Auf einen Test von Open Office mussten die Blinden ganz verzichten: Sie scheiterten bereits an der Installation der benötigten Java Access Bridge [11], die sie wegen unauflösbarer Abhängigkeiten nicht kompilieren konnten. Das gute Zusammenspiel von Microsoft Word mit kommerziellen Screenreadern dagegen ist einer der Gründe, warum Sebastian außer Linux auch Windows benutzt. Daneben lobt er aber das freie Betriebssystem: “Linux kann ein Blinder selbst installieren – Windows nicht.”

Der Workshop hat es gezeigt: Auf dem Weg zu einem benutzbaren Linux-System für den sehbehinderten oder blinden Normalanwender gibt es noch viele Hindernisse zu überwinden. Die Linaccess-Tester sind untypische Benutzer: Sie studieren Informatik, bringen technisches Verständnis und Geduld mit. Außerdem beschäftigen sich schon seit Jahren mit den eingesetzten Programmen.

Mithilfe gesucht

Laut Ellen Reitmayr ist Accessibility ein technisch anspruchsvolles Thema: Toolkits und alle anderen Komponenten des Systems müssen perfekt zusammenspielen – unerwartete Fehler stellen behinderte Benutzer vor große Probleme. Im Projekt Open Usability möchte sie das Bewusstsein der Entwicklergemeinde nicht nur für allgemeine Benutzbarkeit, sondern auch für die Bedürfnisse behinderter Benutzer schärfen.

Die Kollegen von Linaccess bitten in der Zwischenzeit um tatkräftige Mithilfe: Sie möchten ein deutsches Stimmpaket für die freie Sprachausgabe Festival erstellen. Dazu suchen sie Freiwillige, die sich Zeit nehmen, die enorme Zahl von Lautkombinationen einzusprechen, die das System benötigt.