Kategorie-Archiv: Hilfsmittel

Artikel, die sich mit Hilfsmitteln beschäftigen

Fernwartung mit NVDA jetzt kostenlos möglich

Eine der herausragenden Funktionen von JAWS war und ist die Möglichkeit, auf entfernte Rechner der sog. Remote Desktop zugreifen zu können. Dafür wird die Professional-Lizenz benötigt und JAWS muss auf beiden Systemen installiert sein.

Etwas ähnliches gibt es nun auch für NVDA. Auch hier muss auf beiden Maschinen NVDA laufen, aber die Unterschiede sind dennoch beachtlich:

  • Sowohl NVDA als auch die Erweiterung NVDARemote sind kostenlos verfügbar. Jeder ist eingeladen einen Betrag seiner Wahl zu spenden, um eines oder beide dieser Projekte zu unterstützen.
  • NVDA braucht bekanntlich keine Administrationsrechte bei der Installation – sieht man mal von der Verwendung im Anmeldebildschirm ab. Damit dürfte eine Installation von NVDA auf einem Terminalserver o.ä. eine Administrator deutlich weniger Kopfzerbrechen machen als bei JAWS,
  • Mit JAWS und seinem Grafiktreiber hat es bei virtuellen Hosts so seine Tücken. Die akzeptieren nämlich häufig nicht, dass ein Grafiktreiber installiert werden soll, oder sind so weit von der Hardware entfernt, dass die Installation seltsame Fehlermeldungen ergibt. Deshalb war die Nutzung von JAWS-Remote in der Praxis für mich oft nicht möglich. Für “normale” Rechner sieht dies freilich anders aus.
  • Prinzipiell kann man natürlich darauf bauen, dass JAWS oder NVDA auf dem entfernten Rechner laufen und den Audiokanal zu einem umgeleitet wird. Die Verzögerung und die Audioqualität sind hier aber ein echtes Hindernis. Außerdem fällt damit jegliche Brailleunterstützung weg – nichts um von zu Hause arbeiten zu können.

NVDA Remote wird einfach als Erweiterung in ein laufendes NVDA installiert – zur Erinnerung: Es ist problemlos möglich mehrere NVDA-Versionen auf einem Rechner zu betreiben. Die Erweiterung landet allerdings in Ihrem Benutzerverzeichnis und ist somit überall verfügbar.

Die Erweiterung kann hier heruntergeladen werden:
http://nvdaremote.com/download/
Hier gibt es eine sehr knappe Beschreibung der Erweiterung:
http://nvdaremote.com/blog/

Das Release ist noch ganz frisch und man sollte daher nicht verwundert sein, dass die Beschreibung sehr knapp und die Texte noch auf Englisch sind. Es sollte noch erwähnt werden, dass die Entwickler der Erweiterung zwar bekannte Entwickler im Umfeld von NVDA sind, aber die Entwicklung nichts mit dem Team zu tun hat, das NVDA selbst entwickelt – genau wie bei diversen Erweiterungen für Firefox.

Mit NVDARemote ist NVDA wieder ein Stück näher zu JAWS & Co aufgerückt. Arbeitsplätze, die eine Verwaltung entfernter Maschinen benötigen, können nun oft auch mit NVDA betrieben werden – eine Installation des Screenreaders ist in beiden Fällen nach wie vor notwendig. Außerdem dürfte es nun einfacher sein, andere Anwender zu unterstützen, die NVDA verwenden. Hierfür gibt es bei JAWS das Tandem, aber auch da sind ordentliche Lizenzgebühren fällig.

Voice Vision: Werkzeug ohne Werkstoff?

Vor längerem hatte ich über das Projekt “The Voice” www.seeingwithsound.com geschrieben. Es handelt sich um eine recht einfache Methode Bilder in Töne umzuwandeln – sie also zu sonifizieren. Dabei geht es nicht darum sie zu beschreiben oder zu analysieren, sondern ihren Inhalt möglichst verlustfrei akustisch wahrnehmbar zu machen. Da hinter steht die Theorie von Peter Meyer, dass das menschliche Gehirn dazu in der Lage sein sollte solche Bilder die akustisch aufgenommen wurden in eine optische Wahrnehmung umzusetzen.

The Voice gibt es für den PC und für Symbian sowie Android, aber nicht für IPhone. Deshalb hat ein chinesischer Entwickler quasi den gleichen Algorithmus in einer IPhone-App namens “Voice Vision” umgesetzt. die App ist (inkl. Upgrades auf die Vollversion) kostenlos. Wer “The Voice” kennt, kommt hiermit sicher auch schnell zurecht. die Tutorials zeigen anhand von Beispielen wie Bilder “klingen”.

Nun gut, die App funktioniert wie erwartet und man kann erahnen, welche bekannten Gegenstände sich auf den Bild befinden könnten, wenn man weiß, was man vor sich hat. Es wäre also eine Frage der Übung unbekannte Bilder zu erkennen. Dabei muss man wissen, dass sich nur recht grobe Strukturen erkennen lassen können (die Auflösung ist gering und für komplexe Bilder braucht es viel Erfahrung und Wissen über optische Gesetze). Was macht man nun mit einer solchen app? Wo lässt sie sich wirklich anwenden?

Der Entwickler gibt an, dass man mit dem Tool Kanten, Türen etc. erkennen kann. Schön, aber war das bislang wirklich ein Problem? Das IPhone muss man mindestens mit einer hand halten und ausrichten – die könnte man auch zum tasten nach den gleichen Hindernissen verwenden. Außerdem ist die Auswertung der akustischen Echos von Schritten und Klicks bei vielen blinden Anwendern recht gut ausgeprägt, sodass sie auch mit vollen Händen durch die Tür finden. The Voice schlägt eine ideosonnenbrille wie Google Glasses vor. Dabei wären die Hände dann wirklich frei und man „sieht“ ohne etwas in der Hand halten zu müssen. Gleichzeitig unterstützt The Voice Spracheingaben, sodass man die Anwendung anweisen kann, ein- oder auszuzhoomen etc. Dies sind zentrale Unterschiede, die auch ü ber die tatsächliche Anwendbarkeit entscheiden dürften.

Endlich die Freundin auf einem Foto “anschauen”? Das würde nicht viel bringen, da ein solches Bild viel zu komplex wäre. Farben von Klamotten etc. können auch andere Anwendungen oder Geräte erkennen. Geschriebene Texte sollte man wohl besser durch eine OCR jagen, denn die dürfte deutlich leichter den Text extrahieren können.

Leider bietet die App nicht die Möglichkeit durch die eigenen Fotos auf dem Gerät zu stöbern und sich evtl. deutliche Abbildungen anzuhören. Das wäre vielleicht eine interessante Erweiterung.

Ich will nicht behaupten, dass die Anwendung unnütz wäre. Es ist eine Möglichkeit in die Welt der Bilder einzutauchen. The voice hilft hier wiederum, weil man beliebige Bilder öffnen kann, sodass auch einfache zeichnungen von anderen Personen in gewisser Weise erkannt werden können. Durch die Mathematik-funktion (die ausgabe von Grasfen) ist eine sehr pragmatische und interessante Anwendung gelungen.

Kurz: Ich kann mir derzeit nicht recht eine sinnvolle Anwendung vorstellen. Vielleicht hat ja einer meiner Leser eine gute Idee?

IPhone 5 antwortet nicht

Das IPhone hat sich mittlerweile fest als sehr gut zugängliches Smartphone für blinde Menschen behauptet. Allerdings gibt es ein paar Dinge, die wirklich seltsam anmuten.

So gut die sprachausgabe und Unterstützung durch Voiceover auch sein mögen, so irritierend ist es, dass man nur schwer in der Lage ist, ein Telefongespräch zu beenden. Man sollte meinen, dass dies eine Kernfunktion eines Mobiltelefons ist. Wahrscheinlich gibt es hierfür eine einfache Lösung, aber ich habe sie beim besten Willen noch nicht gefunden. das Doppeltippen mit zwei fingern sorgt jedenfalls nicht dafür, dass das Gespräch zuverlössig beendet wird. Also sollten besser Sie auflegen, wenn sie mit einem IPhone-Neuling mit voiceover gesprochen haben!

Eine zweite skurile Verknüpfung besteht darin, dass das Einschalten eines Weckers über Siri automatisch das Telefon auf “nicht stören” schaltet. Wehe jemand versucht sie danach anzurufen. Erkenntnis daraus: Es ist immer eine blöde Idee, wenn die Software schlauer sein will, als der Anwender. Besser man verwendet einen Schnöden Wecker jenseits des Apfeltelefons.

Zuletzt sei noch der Schalter über der Lautstärkeregelung erwähnt, der in einer Stellung das telefon nicht klingeln läßt – egal was Sie in den Menüs eingestellt haben. Das Telefon vibriert, wenn diese funktion eingeschaltet – das Handy also lautlos wird.

Wer übrigens versucht, seinen Account im appstore selbst einzurichten wird vermutlich über die Telefonnummer im Bereich der Rechnungsdaten stolpern. Hier werden zwei nicht richtig zugängliche Steuerelemente verwendet nämlich für Vorwahl und Telefonnummer. Damit klappt dann die Einrichtung des Appstores nicht und das ist ein echter Showstopper.

Microsoft Office Online offenbar gut mit Screenreadern zugänglich

Microsoft hat ja schon länger eine Office-version, die über das Web funktioniert. Also eine sog. Cloud-Anwendung. Frühere Versuche einen solchen dienst mit NVDA & Co. zu nutzen waren immer recht kläglich gescheitert – zumindest als ich das mal probiert habe. Auch www.projectplace.de war überhaupt nicht zugänglich – letztlich ist das auch eine Webanwendung zur Bearbeitung von projektdokumenten.

Auf http://www.blind-geek-zone.net/ wurde nun in einem audiobeitrag Microsofts Onedrive www.onedrive.live.com vorgestellt. Die Bedienung erfolgt eigentlich wie bei einer normalen Webseite bzw. Webanwendung – man wählt menüs, Schalter etc. Im Fall von Onedrive macht der autor sich die Umschaltmöglichkeit von NVDA zwischen Brows mode (dort kann man mit h zu einer Überschrift springen etc.) und dem focus mode (dann werden alle Tasten an die Anwendung durchgereicht) zunutze. Durch das Umschalten, kann man dabei Auswahlen etc. bewusst an Onedrive weitergeben.

Bislang habe ich nur einen kurzen Test gemacht. Die Ergebnisse finde ich erstaunlich:

  • Das Eingeben von Text in Word Online ist wie in einem normalen Mehrzeiligen Textfeld. Allerdings reagiert Word im Web etwas träger und es wird Absatz bearbeitbar vorgelesen, wenn man mit den Pfeiltasten rauf und runter geht.
  • Das nachträgliche Kursivsetzen eines Textbereichs war intuitiv möglich – Text markieren, Focus mode verlassen und den Schalter für kursiv suchen. Das Ergebnis kann anschließend mit NVDA überprüft werden, in dem man die Schriftinformationen auf dem Text abruft (NVDA+f).
  • Eine Rechtschreibprüfung konnte ich durchführen. Allerdings habe ich nicht klar überblicken können, welches Wort genau gemeint war und welche Vorschläge gemacht wurden. Aber das mag an meiner mangelnden Erfharung mit Word Online zusammenhängen – es war eben der allererste Versuch.
  • In Excel werden die Texte zusammen mit den Zellen ähnlich vorgelesen, wie im klassischen Excel – allerdings auch hier verzögert. Ein detaillierter Test steht allerdings noch aus.

Auch wenn ich nur an der oberfläche gekrazt habe, kann man wohl sagen, dass Onedrive eine wirklich nutzbare Onlineversion von Office für Screenreadernutzer ist. ich habe NVDA verwendet, aber andere Screenreader, die die entspr. Zugänglichkeitsstandards einhalten – eine Umschaltung zwischen Browsen und Fokus bieten sie hoffentlich an.

Es ist schön, das Microsoft hier ohne langes Ringen mit Selbsthilfeverbänden etc. eine zugängliche Version für Screenreader erstellt hat. Das ist weit mehr, als man oft anderen Anbietern bei Anwendungen abringen kann. Auch wenn nicht alles leicht bedienbar und reibungslos ist, so ist die technische Machbarkeit doch gezeigt. Rausreden kann sich also nun keiner mehr.

NVDA bläst zum Sturm auf Ofice

Es ist noch nicht lange her, als ich in einem Artikel für die “Gegenwart” über NVDA berichtet hatte. Damals war klar, dass NVDA den anderen Screenreadern im Bereich Microsoft Office unterlegen war. Für viele Anwender war das sicher ein Grund bei ihrem bisherigen Screenreader zu bleiben.

Nun ist der erste Release Candidate von NVDA 2014.3 veröffentlicht worden. Die Liste der Neuerungen enthält fast ausschließelich Verbesserunen für Microsoft Office. Damit dürfte der Vorsprung der Konkurrenten wie JAWS und Kobra weiter dahin schmelzen.

Hier ist der Link zur Testseite von NVDA. Von dort kann man sowohl die Neuerungen einsehen als auch den Release Candidate herunterladen.

Erwägen Sie bitte auch eine Spende für dieses großartige und freie Projekt, denn es wäre sehr ärgerlich, wenn die Weiterentwicklung an der Finanzierung scheitern würde.

Hier nun der Link:
http://community.nvda-project.org/wiki/Test

Gute Berufsmöglichkeiten für blinde Java-Entwickler

In den vergangenen Wochen habe ich mich intensiv in die Entwicklung komplexer Anwendungen mit Java eingearbeitet. Das man mit einem Editor und den Kommandowerkzeugen javac und java gut mit einem Screenreader arbeiten kann, ist nichts Neues.
Die Entwicklungsumgebung Eclipse ist auch schon lange für seine gute Zugänglichkeit bekannt. Wo ist hier also die Überraschung?

Bei der Entwicklung von Mehrschicht-anwendungen sind eine ganze Reihe von Editoren und Werkzeugen notwendig, die nicht automatisch bei der Entwicklung kleinerer Desktop-anwendungen benutzt werden müssen. Da es nur wenige blinde Java-Entwickler gibt, war nicht klar, ob alle diese Werkzeuge genauso gut zugänglich sind, wie man es von den Standardansichten in Eclipse gewohnt ist. Die gute Zugänglichkeit von Eclipse basiert zum Großteil darauf, dass keine Swing-Steuerelemente verwendet werden, sondern native Steuerelemente des Betriebssystems. Dadurch verhält sich das ganze wie jede andere Windows-Anwendung auch. Allerdings ist die Zugänglichkeit genau dann vorbei, wenn es notwendig ist, ein Steuerelement mit anderen Mitteln zu realisieren – z.B. weil es kein entspr. natives Steuerelement auf allen Plattformen gibt. Wie uns auf einer Tagung der BFG IT vor Jahren kompetent erläutert wurde, ist es in solchen Fällen sehr schwer und aufwendig, die Zugänglichkeit einzubauen. Tatsächlich zeigte sich relativ früh ein solches Objekt. Beim Generieren von Entitätsklassen aus den Tabellen einer Datenbank kann man die Spalten und deren Eigenschaften nicht ändern. Glücklicherweise kann man wenigstens alles übernehmen und im Nachhinein im Code bearbeiten.

Ein weiteres Problem tritt auf, wenn man Unittests ausführen will. Hier werden die Ergebnisse (erfolgreich oder fehlgeschlagen) über Icons im Baum angezeigt. JAWS-Anwender können hier die Grafiken beschriften, aber NVDA-Benutzer sehen diese Icons nicht. Das gilt übrigens für alle Icons, die an Bäumen in Swing-Anwendungen hängen. Im Gegensatz zu Eclipse sind sie in Swing-Anwendungen auch für JAWS nicht mehr auslesbar. Hier wäre es wohl notwendig, die Zugänglichkeitsschnittstellen so zu erweitern, dass Objekte zusätzlich zu den Status wie angehakt, ausgewählt etc. auch anwendungsspezifische Status haben können. In Java kann man hierfür jedem Bild einen Alternativtext geben, der als Statustext verwendet werden könnte.

In einigen Projekten ist es notwendig eine ältere Version von Eclipse z.B. Eclipse Juno zu verwenden. Hier fällt auf, dass beim Navigieren im Baum zunächst immer der zuvor ausgewählte Eintrag vorgelesen wird und anschließend der nun selektierte. daran kann man sich zwar gewöhnen, es kostet auf die Dauer aber viel Zeit. Die Lösung für das Problem war verblüffend einfach. Bei neuen Versionen von Eclipse tritt das Problem nicht auf, aber dafür in allen Java-Anwendungen, die einen Baum verwenden. Es fiel auf, dass NVDA für die ältere Eclipse-Version wie für die Java-Anwendungen javaw.exe als Anwendungsnamen identifiziert, während es in der aktuellen Eclipse-Version eclipse.exe ist. für Eclipse gibt es im NVDA-Quellcode eine eclipse.py die mit wenigen Zeilen Code die erste Meldung ausschaltet und damit den Fehler, der eigentlich in der Java-Zugänglichkeitsschnittstelle steckt ausbügelt. Das Kopieren dieser Datei in javaw.py in eigenen Erweiterungsverzeichnis von NVDA behebt das Problem für das alte Eclipse und alle Java-Anwendungen. Herausgefunden habe ich das nicht alleine, sondern durch den Austausch mit James Teh dem zweiten NVDA-Hauptentwickler.

Der Vorfall zeigt auf, dass für Java die bisherigen Konzepte zur Erweiterung von Anwendungen nicht mehr greifen, denn die haben sich immer am Anwendungsnamen orientiert – und dieser ist für alle Java-Anwendungen java.exe oder javaw.exe.

Das Debuggen in Client und Server inkl. dem Verfolgen des Callstacks oder das Inspizieren von Objekten war leicht möglich. Durch die Tastenkürzel für die üblichen Schritt- und Haltepunktaktionen kann man schnell und effizient arbeiten.

Eine echte Barriere war der Installer des Glassfish-Servers, der vollkommen unzugänglich ist. Zum Glück kann man den Server auch als Zip-Datei herunterladen. Das Oracle es nicht schafft, einen zugänglichen Installer bereitzustellen spricht allerdings für sich.

Alles in Allem ist die Erprobung mit verblüffend wenig Hindernissen verbunden gewesen. Dinge wie die oben beschriebenen Steuerelemente und Statusbilder sind zwar ärgerlich, aber keine wirkliche Barriere. Da die Applicationserver wie Glassfish oder Websphere alle über eine Weboberfläche zur Administration verfügen und die verwendeten Plugins in Eclipse sich in den meisten Fällen aus den bereits verwendeten Steuerelementen bedienen, treten auch hier relativ wenig Probleme auf. Ein Hindernis war z.B. das Bedienen des Subversion-Plugins mit dem man den Code gegen die Versionsverwaltung synchronisiert. Vermutlich wird man sich Änderungen und Konflikte über den klassischen Subversion-Client ansehen müssen.

Die Erprobung wurde vollständig mit NVDA durchgeführt. JAWS dürfte wohl ähnliche Ergebnisse liefern, weil spätestens bei Swing-Anwendungen die Zugänglichkeitsschnittstelle in Java das Nadelöhr ist. Was sie nicht liefert sieht keiner der Screenreader und das auslesen der angelieferten Attribute ist keine Herausforderung für einen Screenreader. Ein Offscreenmodell, wie es in Windows-Anwendungen sonst üblich ist, müssten sich die Reader hier mühsam anhand der gemeldeten Positionsangaben der Zugänglichkeitsobjekte zusammenbauen. Bis dahin ist man auf die Tastaturnavigation der Anwendung festgenagelt, oder man muss sich durch den Objektbaum hangeln. Wehe, wenn ein wichtiges Steuerelement für die Arbeit keinen Hotkey oder Menübefehl hat. Apropos: Eclipse ist u.a. deshalb so gut zugänglich, weil es tonnenweise Tastenkürzel gibt.

OK, und was ist, wenn ein Projekt nicht mit Eclipse entwickelt wird? Das kann sehr unterschiedlich sein. Da gibt es z.B. IntelliJ von www.jetbrains.com. Die Anwendung ist vollkommen unzugänglich – man kann NICHTS lesen. Auf eine Supportanfrage wurde ich mit “It is a known issue” auf einen Bugeintrag verwiesen. Der Inhalt ist rasch erklärt: Der Autor ist mir über die NVDA-Entwicklerliste bekannt und er hat alles versucht um nach Kräften zu unterstützen, aber seit dem der Fehler vor einem Jahr angelegt wurde, sind keine Kommentare des Herstellers eingefügt worden. Selbst wenn es einen Fix gäbe, würde s wohl noch lange dauern, bis eine solche Umgebung hinreichend zugänglich ist.

Als dritte IDE gibt es noch NetBeans von www.netbeans.org. Hier fällt positiv auf, dass Zugänglichkeit dort ein Thema ist, dass auf den Seiten diskutiert wird. Das Stichwort heißt hier A11Y. Ein Schnelltest zeigte zwar, dass die Menüs und Editoren zwar grundsätzlich zugänglich sind, aber dass es doch noch an vielen Stellen hakt. Z.B. wird beim Navigieren in einem Java-Editor der Screenreader in einen Baum gerufen, während der Fokus im Editor verbleibt. Beim Versuch die Anwendung im Detail zu justieren, konnte ich den Optionen-Dialog nicht öffnen. Ich vermute aber, dass es sich hier um Details handelt, die man mit dem Hersteller klären könnte.

Fazit

Die Entwicklung komplexer Mehrschicht-Anwendungen ist für blinde Menschen im professionellen Umfeld gut möglich. Es gibt zwar einige Hindernisse und Stolperfallen, aber die sind bei der Komplexität der Anwendungen wohl normal. Es kommt wie immer auf die Details an, ob der Einsatz in allen Projektbereichen möglich ist. Da das Eis wie beschrieben sehr dünn sein kann, habe ich den Rettungsanker schon bereitgelegt: Ich arbeite mich in Python und das Objektmodell von NVDA ein, um im Notfall die benötigten Änderungen umsetzen oder zumindest initiieren zu können. Es ist wohl nur eine Frage der Zeit, bis ich aktiv den Weg freiprogrammieren muss.

Ich hoffe, dass ich mit diesem Artikel anderen blinden Entwicklern ein paar hilfreiche Erfahrungen mitgeben konnte.

Weltweite Konferenz zu NVDA

Am letzten Wochenende fand die zweite NVDA user conference statt. Dafür musste man weder ein Hotel buchen oder verreisen. Es genügte eine leicht zu bedienende Chatsoftware.

Aufgrund der Beteiligung rund um den Globus fand die Konferenz ab 18:00 bis ca 03:00 früh statt.

Neben Informationen und Fragen zur weiteren entwicklung von NVDA stand auch eine Session zur Entwicklung von Erweiterungen bzw. anpassungen auf dem Programm. Eine dritte Sitzung wurde den Umsteigern von JAWS gewidmet.

OK, schön das ich über Vergangenes berichte. Was haben Sie nun davon? Die Konferenz wurde aufgezeichnet und alle Informationen sind unter folgendem Link zu finden:
http://www.nvda-kr.org/en/nvdacon.php

Woher kommen eigentlich die Ellen langen Seiten?

Wenn man in seinem Browser mit einem Screenreader gefühlt unendlich oft nach unten wandern kann, wenn die Liste an Links, Schaltern, Registerkarten und Tabellen im mittleren zweistelligen Bereich ist, dann befindet man sich in einer Webanwendung. Machen sich die Entwickler die Mühe so lange Seiten zu erstellen? Können sie nicht einfach kurze und übersichtliche Dialoge entwerfen?

Nein, denn die Seiten werden i.d.R. aus einer Reihe von Bausteinen generiert. Natürlich entscheiden die Entwickler darüber, welche Komponenten an welcher Stelle ihrer Anwendung angezeigt werden, aber sie sind dabei immer mehr vom HTML-Text entfernt, der beim Anwender im Browser angezeigt wird. Aus wenigen Skriptaufrufen oder deklarierten Komponenten werden dadurch im nu lange und komplexe HTML-Dokumente, die vom Browser einerseits und vom Screenreader andererseits interpretiert werden müssen.

Während bei der Verwendung von PHP der Entwickler den generierten HTML-Code noch relativ gut beeinflussen kann und ungefähr weiß, wie der Code an Ende aussieht, ist dies bei Frameworks wie JSF anders. Der Entwickler deklariert in XML- und XHTML-Dokumenten den Seitenaufbau, deren Verknüpfung und bettet Aktionen etc. ein. Die Objekte mit denen er hantiert sind direkt an die Anwendungslogik gekoppelt, die in Java erstellt wird. Was am Ende tatsächlich im HTML-Code steht, entscheidet die JSF-Implementierung (JSF ist nämlich nur eine Spezifikation). Die Seiten werden also eher komponiert und durch abstrakte Regeln wird ihre Verknüpfung festgelegt.

Beratung bei der Gestaltung von Barrierefreien Seiten

Bislang haben sich die Spezialisten den HTML-code der Seiten angesehen und darauf basierend gezielt Hinweise gegeben, wie die Barrieren entfernt werden können. Das können sie zwar auch bei Webanwendungen tun, aber die verantwortlichen Entwickler haben kaum Kenntnis über den HTML-code, den sie generieren. Sie können ihn auch nur im Rahmen der Möglichkeiten von JSF und den Implementierungen beeinflussen. Damit sind sie in der gleichen Situation, wie die Entwickler von Desktop-Anwendungen. Damit solche Webanwendungen möglichst zugänglich bzw. barrierefrei sind, müssen zunächst die JSF-Implementierungen wie
Prime Faces korrekten Code im Sinne der WCAG erstellen.

JSF-Anwendungen kommen vor allem bei beruflichen Anwendungen zum tragen, weil sie eine komplexe Infrastruktur benötigen und auf verteilte und komplexe Logik ausgerichtet sind. Weil sich in diesem Kontext meistens keine Alternativen Anwendungen verwenden lassen (Ein Unternehmen installiert solche Anwendungen aus handfesten Gründen), wiegen Barrieren hier schwerer als bei Anwendungen im privaten Umfeld.

Wie bei Desktopanwendungen auch, ist die Zugänglichkeit durch das zugrundeliegende Framework eine Grundvoraussetzung, aber alleine nicht ausreichend. Nur der Entwickler weiß, welche Bereiche der Anwendungen mit welchen ARIA-Rollen ausgestattet werden müssen – welche Semantik die Informationen in einem bestimmten Bereich haben. Erst mit der neuesten JSF-Spezifikation ist es möglich geworden, solche Informationen über die Komponenten in den generierten HTML-Code einzuwerfen. Dies muss nun von den Implementierungen unterstützt und umgesetzt werden.
Der folgende Link beschreibt die Situation der Webanwendungen und die technischen Abhängigkeiten recht gut und nachvollzieh bar.
http://blog.akquinet.de/2013/07/26/the-state-of-web-accessibility-in-the-javaee-world/

Der folgende Link verweist auf ein Buch zu JSF und macht die Mächtigkeit und Tragweite von JSF für Webanwendungen deutlich.
http://jsfatwork.irian.at/book_de/jsf.html

Barrieren liegen auf der Lauer

Nun könnte man meinen, dass sich erst bei komplexen Tabellen und überfrachteten Seiten ernsthafte Probleme einstellen. Die Hindernisse finden sich aber schon in viel banaleren Situationen. Z.B. dann, wenn man einen Baum (z.B. ein Inhaltsverzeichnis oder eine Ordnerstruktur) darstellen möchte. Wenn man Glück hat, dann wird die Struktur aus wild in einander geschachtelten Listen zusammengesetzt. Das ist zwar nicht übersichtlich, aber wenigstens kann man den Inhalt lesen. Weil parallele Knoten in einzelnen Listen dargestellt werden, können hier Teile der Navigationstasten des Screenreaders nicht mehr helfen. Wenn man pech hat, und das erwähnte Prime Faces zum einsatz kommt, dann erkennt der Screenreader, dass eine Baumstruktur vorhanden ist, kann sie aber überhaupt nicht auslesen. Das wäre dann i.d.R. ein Knockout-Kriterium für die Zugänglichkeit einer Anwendung, weil sich in solchen Bäumen oft zentrale Informationen wiederfinden.

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:

  1. QT-Anwendungen werden unter Mac OS deutlich zugänglicher
  2. 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.

Mein Hai geht in Teilzeit

Ich habe schon lange auf den Tag gewartet, da NVDA an meinem Arbeitsplatz das Kommando übernimmt. Nich aus Gehässigkeit gegen die kommerzielle Lösung, sondern es sich schon lange abgezeichnet hat. Folgende Ereignisse haben diesen Tag nun wahr werden lassen:

  • Immer mehr unserer verwendeten Webanwendungen lassen sich besser mit Firefox und damit auch mit NVDA verwenden.
  • Der Zugriff auf das Internet ist nur noch via Firefox möglich – und weil viele Dokus dort liegen, bin ich quasi drauf angewiesen.
  • Ich habe endlich das Problem gelöst, dass NVDA bei der Verwendung von Outlook immer eingefroren ist. “schuld” war eine Software namens advanced security for Outlook, die für Catlok verwendet wird. Das ist eine sehr zugängliche Anwendung um die eigenen und die Termine von Kollegen zu überblicken. Nach deinstallation des “Schuldigen” lief NVDA ohne Probleme und dem ständigen Einsatz stand nichts mehr im Weg.

Allerdings brauche ich JAWS noch zum Debugging in Visualstudio und vermutlich auch noch für andere Anwendungen.

Wie auch immer: Ich bin froh, dass es wirklich gelungen ist, als Softwareentwickler produktiv den ganzen Tag mit NVDA zu arbeiten. Das beste daran: Wenn irgendwas zu klemmen scheint, Drücke ich die NVDA-Kombination und die Software wird durchgestartet.

Ich wünsche mir, dass die kommerzielle Konkurrenz wie JAWS endlich aus den Fehlern lernt und Screenreader baut, die stabil laufen und das Abdecken, was die Anwender brauchen. Ich habe den Eindruck, dass oft Funktionen am Bedarf vorbei eingebaut werden.