Schlagwort-Archiv: QT

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.

Zugänglichkeit von QT-Anwendungen – Möglichkeiten und Fallstricke

Auch wenn die Programmiersprache C++ schon Jahre totgesagt ist, es gibt sie noch immer. Mit dem QT-Framework kann man in dieser Sprache modern anzuschauende und leistungsstarke Anwendungen programmieren. Damit nicht genug, das Framework ist unter bestimmten Bedingungen frei verfügbar.
Nährere Infos über QT finden sich hier [[http://www.qt.nokia.com]]

== Wie zugänglich können QT-Anwendungen grundsätzlich sein ==
Von seiner Grundstruktur her, erscheint QT erstmal recht problematisch für Screenreader. Alle Steuerelemente werden selbst gezeichnet und die nativen des Betriebssystems bleiben außen vor. Da erscheint u.U. nicht mehr als ein leeres Fenster.

Aber QT hat sich in vielen Punkten längst um Zugänglichkeit gekümmert. Dabei wird konsequent die Alternative mit speziellen Zugänglichkeitsschnittstellen wie MSAA und IAccessible2 beschritten. Falls ein Screenreader also auf diesem für ihn speziell entwickelten Kanal hört, hat er wiederum gute Chancen reichlich Infos von der Anwendung mitzubekommen. Die Situation ist ein wenig vergleichbar mit der unter Java Swing. auch hier sind nur Informationen über die definierten Schnittstellen verfügbar.

QT braucht allerdings im Gegensatz zu Java keine spezielle Access Bridge und beschickt stattdessen den Screenreader so, wie es vorgesehen ist. Spezielle Installationsorgien und Probleme beim Update sind hier also kein Problem.

== Wie mache ich eine QT-Anwendung für Screenreader zugänglich? ==
Damit eine QT-Anwendung einem Screenreadernutzer sinnvolle Informationen geben kann, muss man als Entwickler konsequent die Attribute
* accessible name – Wie soll dieses GUI-Element für den Anwender benannt werden?
* Accessible Description: Längere Beschreibung des GUI-Elements. Hier können erweiterete Informationen zum Kontext in dem sich die Anwendung befindet angegeben werden.
* Accessible Role: Welcher Typ verwendet das GUI-Element bzw. welche Rolle spielt es in der Anwendung? Hier sind i.d.R nur bestimmte Rollen zulässig und in den meisten Fällen sind sie durch die Steuerelemente bereits korrekt gesetzt.

Der Entwickler sollte zudem diese Beschriftung auch konsequent in Rahmen, Tabseiten – eben in allen Elementen der Oberfläche fortsetzen. Sie werden nicht alle automatisch vorgelesen, aber wenn ein Screenreadernutzer in de Anwendung navigiert, benötigt er zu den lokalen Informationen z.B. Datei zum Hochladen auch den Kontext – welche Datei zum Hochladen soll hier ausgewählt werden? Durch die Navigation mit dem Screenreader im Objektbaum der Anwendung kann diese Information leichter beschafft werden, wenn alle Ebenen sinnvolle Semantik liefern.
Nehmen Sie sich also bitte die Zeit, sich zu überlegen, was in einem Rahmen, einem Register etc. gekapselt wird und was nicht.

Versuchen Sie zu dem Ihre Anwendung mit abgezogener Maus und abgeschaltetem Schirm mit Hilfe eines Screenreaders wie NVDA zu bedienen. Sie finden ihn hier [[http://www.nvda-project.org]] NVDA ist ein nützlicher Begleiter während der Entwicklung. Er braucht keine Installation und über den Sprachbetrachter könnenn Sie sich die Sprachausgabe in einem Fenster anzeigen lassen.

Für den finalen Test braucht es aber wirklich die Situation, dass Sie den Schirm nicht sehen. Erst dann, wenn sie alle Anwendungsfälle Ihrer Anwendung leicht bedienen können und zu jedem Zeitpunkt wissen wo sie sich befinden, ist Ihre Anwendung gut Zugänglich bzw. barrierefrei.

== Eine QT-Anwendung ist mit Zugänglichkeitsinformationen ausgerüstet, es wird aber nichts vorgelesen. ==
1. Zunächst brauchen Sie einen Screenreader der wirklich die Zugänglichkeitsschnittstellen verwendet. JAWS ist leider nicht von dieser Sorte. NVDA liefert hier deutlich bessere Ergebnisse.
2. Unter Windows XP müssen zusätzlich zur Anwendung die sog. Accessibility Plugins in einem Verzeichnis Namens accessible im Anwendungsverzeichnis also parallel zur ausfürhbaren Anwendung installiert werden. Unter Windows 7 scheint das Problem nicht aufzutreten.
Der Anwendungsentwickler sollte diese Plugins erstellen können – sie können beim Übersetzen des QT-Frameworks erstellt werden. Sie befinden sich anschließend im Ordner plugin und dort im Ordner accessible. Es müssen die Plugins der gleichen QT-Version verwendet werden, wie die anwendung verwendet. Ein Kopieren an den richtigen Ort ist ausreichend.

== Wie zugänglich können QT-Anwendungen werden? ==
Wir haben bei [[http://www.david-software.de]] eine Anwendung mit Zugänglichkeitsinformationen ausgerüstet, die neben den üblichen Eingabefeldern, Listen, Registerkarten und Baumstrukturen auch Tabellen enthielt. Diese ist gut und flüssig in der Bedienung. Allerdings wird der Cursor in Eingabefeldern beim Editieren nicht gesprochen, sodass ich manchmal den Text in einem anderen Editor bearbeite und zurückkopiere. Nicht schön und sicher nicht barrierfrei, aber praktikabel.
Ein anderes Problem sind Auswahlfelder, bei denen die gewählte Option nicht unmittelbar vom Screenreader vorgelesen wird, wie sonst üblich. Hier hilft aber das erneute Anspringen des Steuerelements oder ein Screenreadergefehl, der das aktuelle Objekt erneut vorliest.

== Weitere Informationen ==
Wer mehr über die Zugänglichkeit in QT erfahren möchte, der findet Details unter dem folgenden Link:
[[http://doc.qt.nokia.com/4.7-snapshot/accessible.html | Accessibility in QT]]

Arbeit unter Linux mit Screenreadern nach wie vor schwierig

Die Unterstützung des Betriebssystems Linux mit Screenreadern ist nach wie vor sehr rudimentär. Unter [[http://blogs.kde.org/node/4401]] wird berichtet, dass erst jetzt [[http://www.qt-software.com]] unter Linux mit Screenreadern benutzt werden kann.
Der Blog sagt aus, dass QT bereits unter Windows zugänglich ist. Das ist nicht ganz korrekt. Für triviale Controls gilt das zwar, allerdings nicht für Tabellen und komplexere Fensterstrukturen wie Tabwidgets etc.
NVDA ist hier übrigends deutlich besser als JAWS, weil NVDA konsequent IAccessible2 auswertet, währen JAWS sich auf andere Quellen verlässt.
Unter Linux gibt es einige Screenreader, die für die Konsole verwendet werden können. Das ist zwar interessant, hat mit der heutigen Nutzung von Linux nur noch wenig zu tun, weil hier alle grafischen Anwendungen nicht benutzbar sind. Einzige derzeit bekannte Lösung für GNOME ist der Screenreader Orca. Wie NVDA ist auch er in Python geschrieben. Wer sich nicht Stunden mit Installation und Konfiguration herumschlagen möchte – dazu braucht man immerhin sehende Hilfe, sollte die Vinux-Distribution von [[http://www.vinux-project.org]] verwenden. Diese Distribution hat Orca bereits auf Ubuntu installiert und konfiguriert. Der Reader reagiert allerdings relativ träge auf Eingaben.
Alternativ dazu gibt es noch das Projekt SUE, das den Kern des Linux Screenreader (LSR) verwendet. [[http://sourceforge.net/projects/sue/]] Allerdings gibt es bislang von diesem Projekt keine wirklich nennenswerten Fortschritte.