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.
