Freie Software und Barrierefreiheit – Ein Wiederspurch?
Ein Großteil der Software, die ich im täglichen Gebrauch verwende ist Freeware bzw. Open Source. Derartige Software wird oft von Einzelpersonen oder einer Community in der Freizeit entwickelt, und dann der Öffentlichkeit kostenlos zur Verfügung gestellt.
Abgesehen von der freien Verfügbarkeit sind gerade Open Source Projekte deshalb so beliebt, weil auch der Quellcode einsehbar ist, man sich deshalb ansehen kann, wie das Programm funktioniert, und man auch Adaptierungen selbst hinzufügen kann.
An dieser Stelle also ein RIESIGES Danke an all die Entwicklerinnen und Entwickler, die ihre Freizeit dafür verwenden, uns allen das Leben zu erleichtern.
Leider stelle ich aber fest, dass viele Freeware und Open-Source Projekte im Bereich der Barrierefreiheit für Menschen mit Behinderung nicht besonders gut abschneiden. Häufig laufen wichtige Funktionen mit dem Screen-Reader nicht, oder es wird erst gar nichts vorgelesen.
Kürzlich habe ich bei zwei Projekten einen Bug-Report hinterlegt. Einen Hinweis, dass die Software mit einem Screen-Reader nicht benutzbar ist, und es fein wäre, wenn man diesen Umstand ändern könnte. Bei einem Projekt erhielt ich die Rückmeldung, dass der Entwickler das Projekt im Prinzip für seine Bedürfnisse schreibe, und die Nutzung durch Screen-Reader von ihm nicht wirklich gebraucht werde, daher werde er hier sicher keine Zeit investieren. Es stünde mir aber natürlich frei, die entsprechende Funktionalität selbst zu implementieren, der Source-Code stehe ja zur Verfügung. Prinzipiell kein Problem, nur wer hat schon die Ressourcen bei jedem Projekt selbst Hand anzulegen.
Bei einem weiteren Projekt erhielt ich die Rückmeldung, dass Apple eine API nicht herausgäbe, und es dem Entwickler daher nicht möglich sei, diese Funktionalität auf einfache Weise zu implementieren. Man müsse hier tiefgreifende Veränderungen durchführen – aber der Entwickler habe das geplant.
Meist muss nur die Accessibility-API des jeweiligen Betriebssystems bzw. der verwendeten Programmiersprache bedient werden, und viele Accessibility-Hürden gehören der Vergangenheit an. Es ist natürlich zusätzlicher Aufwand, Buttons und andere Elemente mit sinnvollen Bezeichnungen zu versehen. Häufig kommt es daher vor, dass mit dem Screen Reader “Button 25″, “Button 53″ oder gar nur “btn zu hören bekommt. Ich kenne das von eigenen Projekten. Man ist sich des Umstandes bewusst, dass hier Elemente zu benennen sind, verschiebt dies aus Zeitknappheit, Unlust oder Faulheit, und vergisst es dann. Man sieht den Button ja optisch, und das Programm funktioniert somit einwandfrei.
Manchmal ist die Programmier-Umgebung selbst das Problem. Ein Beispiel: Während QT mit jeder Version mehr Accessibility-Features aufweist, gestaltet es sich schwierig, eine Anwendung, die in Python geschrieben ist und die Python-QT-Bridge verwendet barrierefreier zu machen, da gewisse Funktionen von QT einfach nicht vorhanden zu sein scheinen. Ein Prominenter Vertreter dieser Gattung ist Calibre. Calibre ist ein Muss für alle E-Book-Fans. Es verwaltet e-Books, kann zwischen den verschiedenen Formaten konvertieren, und in den neuesten Versionen auch ePub und Kindle Dateien direkt bearbeiten. Der Entwickler ist sehr aktiv und bringt im Wochentakt neue Aktualisierungen heraus. Calibre ist in Python geschrieben, und verwendet die QT Bibliothek. Dank dieser Kombination ist die Software sehr flexibel und auf verschiedenen Betriebssystemen installierbar. Aus den zuvor genannten Gründen ist Calibre mit Screen-Readern aber nicht bedienbar.
Auch die freue Office-Suite LibreOffice (bzw. OpenOffice) war lange Zeit mit Screen-Readern nicht vernünftig nutzbar. Dank der Java Accessibility Bridge sieht hier die Situation heute anders aus.
Juristisch gesehen…
Dank Bundes Behindertengleichstellungsgesetz (BGStG) hat man als Mensch mit Behinderung in Österreich über das Instrument der Schlichtung die Möglichkeit auf eine Barriere hinzuweisen, und notfalls den Anbieter wegen Diskriminierung zu belangen und Schadenersatz zu fordern. Bei Kommerziellen Produkten und jenen, die von Behörden und Institutionen der Öffentlichkeit zur Verfügung gestellt werden funktioniert dies auch oft. Zumindest wird man sich auf Anbieter-Seite des Problems meist bewusster, und sucht in der Regel nach einer Lösung. Bei kostenlos angebotener Software wird dies jedoch schwierig, da eigentlich niemand einen finanziellen Gewinn erwirtschaftet, und die Projekte meist auch nicht aus staatlichen Mitteln finanziert werden.
Fazit
Es ist schade, dass viele unverzichtbare Tools und Apps für Menschen mit Behinderungen nur teilweise oder gar nicht nutzbar sind. Ich verstehe aber auch die Entwicklerinnen und Entwickler, die ihre Freizeit investieren, damit es diese Software überhaupt gibt. Mir fällt auf die Schnelle auch kein Lösungsweg ein. Denkbar wäre eine Initiative zur Usability- und Accessibilityevaluierung bzw. Verbesserung von Open Source Projekten, mit dem Ziel Freie Software für möglist viele Menschen gebrauchstauglich zu machen.
Was mein Ihr dazu?
