Schlagwort-Archiv: Accessibility

QT 5.3 und 5.4 bringen große und positive Veränderungen für die Zugänglichkeit

Offenbar wird in QT weiterhin fleißig an der Verbesserung der Zugänglichkeit gearbeitet. Das bedeutet auch, dass es neben Java ein weiteres plattformunabhängiges GUI-Framework gibt, für das eine gewisse Zugänglichkeit vorhanden ist.

Der folgende Blog-Artikel beschreibt die Änderungen in QT 5.3 und 5.4, die für diesen Bereich zu erwarten sind:
[[http://blog.qt.digia.com/blog/2014/05/14/accessibility-in-qt-5-3/]]
Dies betrifft vorallem zwei Dinge:
# QT-Anwendungen werden unter Mac OS deutlich zugänglicher
# Die Infrastruktur wird ab QT 5.4 nicht mehr als Plugins sondern direkt im Kern bereitgestellt. Das heißt, dass Software nicht mehr ohne die Schnittstellen ausgeliefert werden kann. Java hat diesen Schritt bereits vollzogen und es uns damit erheblich leichter gemacht.

Wir können also wohl positiv auf die weitere Entwicklung bei QT hoffen.

Einige Autoren von Anwendungen meinen, dass die Zugänglichkeitsschnitstellen in QT instabil seine und liefern sie teilweise deshalb bewusst nicht aus. Der Autor von Caliber sei hier beispielhaft genannt. Aber in Wahrheit sind die Schnittstellen nur eine Art Softwaretest. Durch die Verwendung eines Screenreaders werden viele Anfragen an das Datenmodell der Anwendung gestellt und wenn es kleine Fehler hat, dann stürzt die Anwendung gnadenlos ab. Verhindern können das die Anwendungen nur, wenn sie ein sauberes und stabiles Datenmodell erstellen. Diese Aussage ist keine graue Theorie, sondern erlebte Praxis. Eine Anwendung von uns stürzte mit Screenreaderverwendung solange ab, bis wir das Modell robuster und korrekter im Sinne der QT API gemacht haben. Und schwups, läuft die Anwendung problemlos mit NVDA.

Also: Ich freue mich sehr über diese Entwicklung.

Erstellen von PDF-Dokumenten aus Microsoft Word

Bei der Erstellung von PDF-Dokumenten wird das Dokument häufig zunächst in Word erstellt und anschließend in ein PDF-Dokument umgewandelt. Dabei kann man in Bezug auf die Zugänglichkeit des PDFs einiges richtig oder auch falsch machen.
== Verwenden eines PDF-Druckers ==
Es funktioniert wie beim Ausdrucken des Dokuments. Man gibt lediglich den Dateinamen des PDFs ein und schon hat man eine fertige Datei. Ein bekannter Drucker dieser Sorte ist freepdf. Die Software installiert sich als normaler Drucker unter Windows und kann in jeder Anwendung verwendet werden.

Solche PDF-Dokumente sind i.d.R. nicht zugänglich, weil sie die Seiten meistens als Grafik im PDF ablegen.
== Spezielle Software zum Export zugänglicher PDF-Dokumente ==
In den letzten Tagen gab es einige Meldungen über verfügbare Plugins für Word, um das Erstellen von barrierefreien PDF-Dokumenten zu ermöglichen. Während ein Tool aus der Schweiz
http://www.zhaw.ch/medien
eher ernüchternde und teilweise deffekte Resultate liefert, soll in Kürze ein weiteres Tool die Bühne betreten. Hier der Link zum Artikel:
http://blog.axespdf.com/index.php/leserseite/items/start-public-beta-axespdf-fuer-word.html

Das ganze kollidiert mit den bereits vorhandenen Möglichkeiten PDF-Dateien aus Word heraus erstellen zu können. Deshalb müssen sich solche Anwendungen an den Ergebnissen der Bordmittel messen lassen.
== Bordmittel ==
Word 2010 bietet von sich aus die Möglichkeit, das Dokument als PDF zu speichern. Das Resultat ist verblüffend gut zugänglich. Bei mehreren Dokumenten konnte ich feststellen, dass die folgenden Features gut umgesetzt waren:
* Die Meldung, dass das Dokument nicht getagt ist, entfällt.
* Überschriften sind korrekt ausgezeichnet.
* Tabellen sind gut lesbar
* Listen ung geschachtelte Listen sind gut lesbar.

Ein entscheidender Vorteil bei eder integrierten Lösung in Word ist, dass viele Autoren sie intuitiv benutzen und damit ohne es zu wissen zugängliche PDF-Dokumente erstellen.

== Defizite mit speziellen Plugins ausgleichen ==
Autoren von speziellen Plugins argumentieren oft damit, dass die Bordmittel bestimmte Funktionen nicht umsetzen bzw. das Ergebnis unbefriedigend ist. Daher wird versucht speziell auf Zugänglichkeit zugeschnittene Plugins zu entwickeln, die diese Defizite vermeiden.

Nach meinen Erfahrungen aus der Softwareentwicklung ist ein solches Vorhaben nur dann sinnvoll, wenn dauerhaft ein Team hinter einem solchen Projekt steht – es sich also nicht nur um ein kurzes befristetes Forschungsprojekt handelt. Dann hätte man besser daran getan Schwachstellen gegenüber Microsoft zu melden oder das ganze von Beginn an als quelloffene Initiative zu starten.

Die größte Hürde in der Praxis wird aber wohl sein, Anwender davon zu überzeugen, Word so einzusetzen, wie es gedacht ist. Für technikaffine Leute klingt das logisch, aber ich selbst kenne viele Anwender, die bereits bei Formatvorlagen den Sinn nicht einsehen mögen. Von Alternativtexten für Bilder etc. ganz zu schweigen.

Bücher für Kindle jetzt auch für Screenreaderbenutzer zugänglich

= Einführung =
Amazon verwendet schon seit einigen Jahren ein spezielles Format für seine E-Book´s. Das Lesegerät für diese Bücher ist der sog. Kindle. Kindle ist bislang nicht für blinde und sehbehinderte Menschen nutzbar. Das ist um so ärgerlicher, als Amazon hier sehr viele Titel anbietet.

= Lösung =
Wie auf [[http://www.blindcooltech.com]] in einem aktuellen Podcast berichtet wird, gibt es eine App, um Bücher im Kindle-Format am PC zu lesen. Damit das ganze für Screenreader nutzbar wird, braucht man noch ein Accessibility-Plugin.
= Meine Meinung zur Lösung =
* Es ist gut, dass es überhaupt eine Lösung für das Kindle-Format gibt. Wenn man Glück hat, konnte man Bücher auch in einem anderen Format erwerben, aber sicherlich sind mit der Lösung viele neue Bücher zugänglich geworden.
* Die Tatsache, dass man ein Plugin für die App braucht, damit sie für Screenreader zugänglich wird, wirft kein gutes Licht auf die Entwickler. Warum integriert man solche Dinge nicht gleich?
* Wie der Podcast demonstriert, werden eine Menge Kurztasten für das Lesen der Bücher benötigt. Für geübte kein Problem, aber mir ist es immer lieber, wenn ich aus Menüs auswählen und dabei die Kurztasten lernen kann.
* Die demonstrierte Navigation innerhalb der Anwendungen macht einen soliden Eindruck und dürfte für jeden – auch für ältere erlernbar sein.
* Die Software bringt offenbar ihre eigene Sprachausgabe mit. Offenbar hat sich das mit SAPI immer noch nicht weit genug durchgesetzt. Da kauft man u.U. eine teure SAPI-Stimme, um wenigstens etwas Lesegenuss zu haben und muss sich dann mit einer eingebauten Sprache abgeben?
* Der Text ist nicht für JAWS und damit auch wohl nicht für andere Screenreader lesbar. Das Mitlesen auf der Braillezeile fällt somit flach.
* Ob es eine Version in deutsch gibt, weiß ich nicht.
= Fazit =
Die begonnene Lösung sollte weiter verbessert werden,. Speziell die Integration von SAPI-Sprachen und das Lesen über die Braillezeile sollten wir einfordern.

Blind unter Linux arbeiten scheint nach wie vor sehr mühsam

Der Screenreader Orca kommt offenbar noch nicht so recht in Fahrt. Zumindest fehlt die Unterstützung fürKDE und offenbar ist es nicht einmal möglich, ohne Weiteres Texte zwischen GUI und Shell auszutauschen.
Weitere interessante Aspekte über die Arbeit mit Orca unter Linux liefert der folgene Blog:

Storm Dragons Blog.

Neuer Trend Weboffice

Der neue Trend Weboffice wirft seine Schatten voraus

Die letzte Ausgabe der C’T stellt eine Reihe von Officelösungen vor, bei denen man gemeinsam an Dokumenten über das Internet oder ein Intranet einer Firma arbeiten kann. Um zu einem papierlosen Büro zu gelangen, braucht es ein gutes Dokumentenmanagement. Hierbei muss u.a. geregelt werden, wer wann welches Dokument sehen und wie bearbeiten darf. Die zentrale Ablage von Dokumenten hat viele Vorteile – wer hat nicht schon einmal eine veraltete Version verwendet? Aber diese Zusammenarbeit wirft auch viele Probleme auf.

Gemeinsames Arbeiten über das Web

Es ist nun wirklich ein alter Hut, dass ein ganzes Team an einem Projekt, Buch oder was auch immer arbeitet. Meistens dadurch, dass einem Mitglied ein bestimmter Teil zugewiesen wird, werden Konflikte vermieden. Selbst in der Softwareentwicklung ist das gemeinsame Arbeiten an einer Quelldatei bzw. an einer´Methode sehr selten und i.d.R. Hinweis auf eine schlechte Abstimmung. Aber Officedokumente sind keine Sammlung von Textdateien, wie sie in Softwareprojekten anzufinden sind. Man kann sie nur mit speziellen Programmen ansehen und darüber bearbeiten. Sie bestehen aus großen Dateien. Das Versions- und Konfliktmanagement müssen also vollständig von der Software zur Anzeige der Dokumente abgeleistet werden.

Entgegen zu parallelen Änderungen an Quellcode wird hier also simultan an einer Datei gearbeitet. Die Anwendung muss entscheiden, welche Teile eines Dokuments als atomar gelten – was darf immer nur ein Anwender gleichzeitig bearbeiten und welche semantischen Zusammenhänge zwischen ihnen gelten. Bearbeitet z.B. ein Anwender ein Kapitel einer wissenschaftlichen Abhandlung, so wird er auch das Inhalts- und Literaturverzeichnis aktualisieren müssen. außerdem wird es zu bestimmten Phasen eines Dokuments notwendig sein, den Umfang von Änderungen zu beschränken. Ein Korrekturleser darf z.B. nur einzelne Wörter ändern oder einen Satzbau korrigieren, während er keine Absätze einfügen oder löschen darf. Außerdem finden die Änderungen in Echtzeit statt und nicht wie bei der Versionsverwaltung wie SVN transaktionsorientiert.

Ist so etwas für Anwender wirklich praktikabel?

Wer einmal ein paar Branches in einer Versionsverwaltung wie SVN verwaltet hat, weiß, dass konflikte und parallele Änderungen, auch bei einem wirklich guten Versionskontrollsystem wie SVN, Arbeit und Zeit bedeuten. Das gilt um so mehr, als die o.g. Situation deutlich komplexer ist und in echtzeit stattfindet – bei SVN finden die Konflikte zum Zeitpunkt des Eincheckens statt. Es muss also darum gehen, Konflikte schon von vornherein zu minimieren und falls notwendig die beteiligten entspr. zu schulen. Eine Sekretärin wird sicher schnell damit überfordert, mehrere Versionsstände im Auge zu behalten und die relevanten Änderungen zusammenzuschieben. Damit bleibt die Frage: Ist das Zusammenarbeiten an einem Dokument wirklich praktikabel, selbst wenn es technisch machbar ist?

Zugänglichkeit für blinde Menschen

Zu allem Überfluss kommt nun für blinde Menschen, die einen Screenreader benutzen, eine weitere Komplexitätsstufe hinzu. Es ist noch nicht klar, ob Techniken wie ARIA etc. ausreichend sind, um weboffice-Anwendungen hinreichend zugänglich zu machen. Im Endeffekt könnte es um viele Arbeitsplätze von blinden Menschen gehen, weil viele in Büros größerer Firmen und Behörden arbeiten. Falls nun das gesamte Office auf eine Webversion umgestellt wird, müssen mehrere Dinge gleichzeitig gelöst werden:

  • Die Officefunktionen, die über Webbrowser bereitgestellt werden, müssen zugänglich sein. Das bedeutet das Abgreifen von bestimmten Informationen über einzelne Teile eines Dokuments (Zellen einer Tabelle oder Folien einer Präsentation)
  • Erarbeiten eines Konzepts, wie konkurrierende Änderungen und verschiedene Versionen eines Dokuments dargestellt werden können – alleine farbige Darstellungen sind schon für sehende Menschen komplex.
  • Anpassen der Zugänglichkeit an die verschiedenen Webtechniken, die bei den Anwendungen zum Einsatz kommen – Flash, Javascript etc.

Entwicklern von Screenreadern steht also nach wie vor viel Arbeit ins Haus. Da wäre es gut, wenn einige der vielen Bugs in verbreiteten Screenreadern schnell behoben würden.