Schlagwort: barrierefreiheit testen

Wie kann barrierefreie Software entwickelt mit .net bzw. C# auf Accessibility getestet werden

Im Artikel „Barrierefreie Software-Entwicklung (=Accessibility) mit .net bzw. C#“ ging es darum wie man mit .net barrierefreie Software entwickelt. In diesem Artikel möchte ich besprechen wie man Barrierefreiheit bei Software die mit .net bzw. C# entwickelt wurde testen kann.

 

Trotz redlicher Bemühungen die Software barrierefrei zu entwickeln, kann es sein, dass man etwas vergisst oder übersehen hat. Deswegen sollte man, bevor man einer Software das Prädikat „barrierefrei“ verleiht, testen ob dies auch zutrifft. Da es höchst unwahrscheinlich ist, dass jeder Software-Entwickler einen Menschen mit Behinderung greifbar hat, welcher die Software testet, ist es sinnvoll, dass hierfür Tools entwickelt worden sind. Microsoft hat zwei Open Source-Tools entwickelt um Barrierefreiheit bei Software zu testen. Das eine Tool heißt „UI Automation Verify“ und das andere „UI Accessibility Checker“.
„UI Automation Verify“ ist ein Framework um Microsoft UI-Automation-Implementierungen automatisiert Prüfen zu können. Ich möchte mich in diesem Abschnitt mit dem AccChecker genauer beschäftigen.
Den AccChecker gibt es als Konsolen- und Windows-Anwendung. Ich werde hier das Verfahren mit der Windows-Anwendung beschreiben die sich hinter der AccCheckUI.exe verbirgt. Ob man zuerst den AccChecker und dann die zu testende Anwendung startet oder umgekehrt ist egal. Links oben im Acc-Checker-Fenster gibt es nun 3 Möglichkeiten, das zu prüfende Fenster bzw. Anwendung auszuwählen.
Ich entscheide mich für das auswählen eines Fensters aus der auf klappbaren Liste, weil es wohl am einfachsten ist. Unten kann ich ein „suppression file“ auswählen in dem ich festlegen, kann welche Fehler ignoriert werden. Auf der rechten Seite gibt es die Überschrift „Verification Routines“. Hier kann angeklickt werden, welche Dinge überprüft werden soll. Da die Dokumentation nicht gerade ein Highlight ist und zum Teil gewisse Fakten verschweigt, möchte ich nachfolgend diese Optionen etwas erläutern und berichten, wie es mit der Praxistauglichkeit aussieht.
Wir fangen an mit den Eigenschaften.

CheckAccessKeys
Wenn diese Option angeklickt ist, wird überprüft ob ein Accesskey doppelt vergeben ist.Leider bekommt man nur mitgeteilt wo der Accesskey zum zweiten mal vorkommt, wo er aber das erste mal vorkommt muss man selbst herausfinden.enn an einen Menü oder Schalter kein Accesskey vergeben wurde, wird einem das nicht mitgeteilt.

CheckRole
Hier kann überprüft werden ob den einzelnen Komponenten eine AccessibleRole vergeben wurde oder nicht. Standardmäßig ist im Eigenschaftenfenster von Visual Studio 2008 default eingestellt bei der Eigenschaft „AccessibleRole“. Wenn hier als Wert „None“ angegeben wird, bringt der AccChecker eine Fehlermeldung.

CheckBoundingRect
Diese Überprüfungsroutine bestätigt, dass jedes fokusierbare Element der Benutzeroberfläche eine rechteckige Begrenzung hat, die für Anklick-Tests genutzt werden kann.

CheckState
Diese Überprüfungsroutine bestätigt, dass jedes fokusierbare Element der Benutzeroberfläche einen gültigen, logischen Aktiven Zugänglichkeitsstatus zurück meldet.

CheckName
Diese Überprüfungsroutine bestätigt, dass jedes fokusierbare Element der Benutzeroberfläche einen gültigen, logischen Aktiven Zugänglichkeitsnamen zurück meldet.

Unter der der Überschrift Tree (Baum) finden Sie nachstehende Optionen

CheckNavigate
Diese Überprüfungsroutine benutzt die IAccessible::accNavigate Methode um zu bestätigen, dass die Navigation zwischen den „Eltern“, dem „Kind“ bzw. den „Geschwister Elementen übereinstimmend und vorhersehbar ist.

CheckParentChild
Diese Überprüfungsroutine bestätigt, dass Eltern->Kind-Beziehungen im Elementebaum übereinstimmend und vorhersehbar sind.

HitTesting
Diese Option ist im Programm nicht vorhanden, aber in der Dokumentation. Diese Überprüfungsroutine bestätigt, dass alle Elemente an den Koordinaten die durch „AccessibleObjectFromPoint angegeben werden gültig sind und sich innerhalb des überprüften Ziels befinden.

Consistency (=Konsistenz)

Screen Reader
Diese Überprüfungsroutine übersetzt alle sichtbaren Elemente des zu überprüfenden Ziels und zeigt sie in einer Listenansicht in der Reihenfolge, in welcher der Standard Screen Reader sie dem Benutzer meldet. Wenn diese Option ausgewählt wurde, erscheint im linken Teil des Fenster ein Register „Screen reader“.

Navigation
Tree Depth Check (CheckTreeDepth)

Zunächst ist zu erwähnen, dass es hier unterschiedliche Begriffe gibt. In der Programmoberfläche steht CheckTreeDepth und in der Dokumentation steht Tree Depth Check.
Diese Überprüfungsroutine sendet Tab oder Umschalt- Tab Zeichen als Eingangssignal an das zu überprüfende Ziel um zu bestätigen das die Benutzeroberfläche des Zielsystems für standard Tastatur Navigation weder allzu sehr komplex oder unerreichbar ist.

Check Tabbing
Diese Überprüfungsroutine sendet Tab oder Umschalt Tab Zeichen als Eingangssignal an das zu überprüfende Ziel um zu bestätigen das alle fokusierbaren Elemente das Benutzeroberfläche in einer geordneten Art und Weise über eine Standard Tastatur Navigation zu erreichen sind.

Soweit zu den Einstellungsmöglichkeiten des AccCheckers.
Hat man nun das zu prüfende Fenster ausgewählt und auf der rechten Seite die entsprechenden Optionen angeklickt, startet man die Überprüfung mit anklicken des Schalters „Run Verifications“.
Nach erfolgter Überprüfung erscheint oben ein Register „Results“, „Tree“ und bei entsprechend ausgewählter Option „Screen reader“. Wenn Sie im Register „Results“ keine Einträge sehen, heißt bedeutet dies, dass keine Fehler gefunden wurden und Ihre Anwendung somit barrierefrei ist.
Wurden Fehler gefunden werden diese im Register „Results“ angezeigt. Wenn man in der Liste „Results“ auf einen Fehler klickt, sieht man unten nähere Infos zu diesem Fehler. Sollte man mit der Fehlermeldung nichts anfangen können, kann man durch einen rechten Mausklick und das anklicken des Kontextmenüpunktes „Help“ eine genaue Beschreibung zum Fehler bekommen.

Java-Software auf Barrierefreiheit (Accessibility) testen

Im letzten Artikel haben wir die Grundlagen der barrierefreien Software-Entwicklung mit der Programmiersprache Java angeschaut. In diesem Artikel schauen wir an, wie Java-Software auf Barrierefreiheit getestet werden können.

Angenommen Sie haben sich richtig Mühe gegeben Ihre Java-Software barrierefrei zu entwickeln und möchten nun wissen, ob die Software wirklich barrierefrei ist. Welche Möglichkeiten gibt es?

Zunächst mal muss man feststellen, dass unter Umständen barrierefrei nicht barrierefrei ist. Wenn eine Software für eine bestimmte Person oder Personengruppe(z. B. Blinde Menschen) mit einer bestimmten Behinderung barrierefrei gemacht werden soll, ist das nicht so zeitaufwendig, wie eine barrierefreie Software die alle möglichen Behinderungsarten berücksichtigen soll.

Ein Software die für blinde Menschen barrierefrei entwickelt werden soll, kann anschließend von einem blinden Menschen auf Barrierefreiheit getestet werden.Wenn eine Software sämtliche Behinderungsarten berücksichtigen soll ist diese Art von Test keine gute Idee.

Die Entwickler von Java, die Firma Sun, haben auch über dieses Problem nachgedacht.Deswegen entwickelten Sie eine Software mit der Java-Anwendungen auf Barrierefreiheit testen kann. Die Software heißt „Java Accessibility Helper“.

Mit dem „Java Accessibility Helper“ kann man Java-Anwendungen auf alle wichtigen Kriterien der Barrierefreiheit testen. Zum Beispiel kann mit dem Java Accessibility Helper getestet werden ob eine Java-Anwendung nur mit Tastatur bedienbar ist. Blinde und viele Sehbehinderte Menschen arbeiten nur mit Tastatur und nicht mit der Maus.

Der Java Accessibility Helper kann hier runter geladen werden: Java Accessibility Helper