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 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 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 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:
Accessibility in QT

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>