Accessibility-Workshop in Berlin

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.