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.

Accessibility: Barrierefreie Software-Entwicklung mit .net bzw. C#

Im Artikel „Richtlinien zur barrierefreier Software-Entwicklung ( Accessibility ) mit .net bzw. C#“ ging es um Richtlinien wie man mit .net barrierefreie Software entwickelt. In diesem Artikel geht es um die konkrete Umsetzung der Richtlinien.Sie erfahren in diesem Artikel konkrete Schritte zur Entwicklung von barrierefreie Software mit .net bzw. C#.

Im Artikel „Richtlinien zur barrierefreier Software-Entwicklung ( Accessibility ) mit .net bzw. C#“ ging es um Richtlinien wie man mit .net barrierefreie Software entwickelt. In diesem Artikel geht es um die konkrete Umsetzung der Richtlinien.Sie erfahren in diesem Artikel konkrete Schritte zur Entwicklung von barrierefreie Software mit .net bzw. C#.

Die erste Programmiersprache welche die Entwicklung von barrierefreie Software unterstützte war Java. Mehr dazu können Sie im Artikel „Barrierefreie Software-Entwicklung (Accessibility) mit Java“. Bei den Programmiersprachen Delphi und C++ fehlt eine Unterstützung von Haus aus.

Eine wichtige Voraussetzung für eine barrierefreie Software ist die Unterstützung von Eingabehilfen wie z. B. Screenreader. Damit diese Eingabehilfen die entsprechenden Informationen bekommen, besitzen .net-Komponenten haben hierfür folgende Eigenschaften:

AccessibleName:
Die Eigenschaft „AccessibleName“ ist eine Kurzbeschreibung der entsprechenden Komponente

AccessibleDescription:
Die Eigenschaft „AccessibleDescription“ ist eine Textbeschreibung der visuellen Darstellung dieser Komponente.

AccessibleRole:
Die Eigenschaft „AccessibleRole“ beschreibt die Aufgabe, die an Eingabehilfen übermittelt wird. Die zulässigen Werte werden von der AccessibleRole-Enumeration definiert. Der Wert wird von vielen Eingabehilfen verwendet, um zu ermitteln, um welche Art von Schnittstellenelement es sich bei dem Objekt handelt.

AccessibilityObject:
Enthält eine AccessibilityObject-Instanz, die für die Eingabehilfe Informationen über das Steuerelement enthält. Die Eigenschaft ist schreibgeschützt und wird vom Designer festgelegt.

AccessibleDefaultActionDescription:
Enthält eine Beschreibung der Standardaktion des Steuerelements. Diese Eigenschaft kann nicht zur Entwurfszeit festgelegt werden, sondern nur per Programmcode.

Hier kurz ein Beispiel wie man diese Eigenschaften setzt.

neuToolStripMenuItem.AccessibleName = „Datei neu“;
neuToolStripMenuItem.AccessibleDescription = „Neue Textdatei anlegen“;
neuToolStripMenuItem.AccessibleRole = AccessibleRole.MenuItem;

Des weiteren ist es wichtig wie oben schon erwähnt wird, dass die Software den Kontrastmodus unterstützt. Zum Unterstützen des Kontrastmodus kann folgende Methode verwendet werden:

privatevoid KontrastModus()

{

if (SystemInformation.HighContrast)

{

foreach (Control vControl inthis.Controls)

{

vControl.BackColor = SystemColors.Control;

vControl.ForeColor = SystemColors.ControlText;

}

}

}

Um die Bedienbarkeit der Software auch über Tastatur zu gewährleisten, ist es wichtig auf die Tabulatorreihenfolge zu achten. Jede .net-Komponmente hat eine Eigenschaft “TabIndex” welcher man eine Zahl übergeben kann. Mit dieser Zahl legt man fest, in welcher Reihenfolge die Komponenten aktiviert werden, wenn der Anwender die Tabulatortaste drückt.

Eine weitere Möglichkeit die Bedienbarkeit von Software über Tastatur zu verbessern, ist das vergeben von Shortcuts für Labels, Buttons, Grouboxen und Menüs. Das erstellen eines Shortcuts macht man, in dem man vor einem bestimmten Buchstaben einer Beschriftung ein “&”-Zeichen setzt. z. B. “&Suchen”.

Der Anwender kann nun durch gleichzeitiges drücken von der Taste “Alt” und “s” den Schalter Suchen aktivieren.

Bei Menüshortcuts ist es empfehlenswert dem Anwender eine Möglichkeit bereitzustellen, diese selber anzupassen,da Menschen, bei welchen behinderungsbedingt nur eine Hand funktionstüchtig ist, mit Tastenkombinationen Ihre Schwierigkeiten haben.

Wenn Sie alle diese Dinge berücksichtigen, haben Sie einen wichtigen Schritt in Sachen barrierefreie Software gemacht.

Accessibility: Richtlinien zur barrierefreier Software-Entwicklung mit .net bzw. C#

In diesem Blogartikel möchte ich die Richtlinien von Microsoft für .net bzw. C# zur barrierefreier Software-Entwicklung besprechen. Wenn eine Software barrierefrei ist, dann ist Sie für Menschen mit Behinderung verwendbar.

Im Artikel „Was ist eine barrierefreie Software“ habe ich erklärt welche Kriterien erfüllt werden müssen, damit eine Software barrierefrei ist. Microsoft hat in ihrer Dokumentation, die MSDN, Richtlinien veröffentlicht wie eine Standardsoftware barrierefrei bzw. behindertengerecht gemacht werden kann. Ich werde hier die Richtlinien wiedergeben und erklären.


Punkt 1: Unterstützung der Systemsteuerungseinstellungen für Größe, Farbe, Schriftart und Eingabe

Unterstützung der Systemsteuerungseinstellungen für Größe, Farbe, Schriftart und Eingabe. Wenn die Benutzer die Einstellungen der Systemsteuerung ändern, wird die Größe der Menüleiste, der Titelleiste, der Ränder und der Statusleiste automatisch geändert. In dieser Anwendung müssen keine weiteren Änderungen an den Steuerelementen oder dem Code vorgenommen werden

Erklärung:
Microsoft hat in jedem Windows, wie oben erwähnt, in der Systemsteuerung einige Einstellungsmöglichkeiten die Menschen mit Behinderung zu gute kommen. Deswegen ist es unabdingbar, dass eine entwickelte Software diese Einstellungen übernimmt und nicht ignoriert. Es wäre zum Beispiel kontraproduktiv, wenn ein Mensch mit einer Sehbehinderung sich in der Systemsteuerung große Schriftarten einstellt und in der Software erscheinen alle Zeichen in der Schriftgröße 10.


Punkt 2: Unterstützung des Kontrastmodus

Erklärung:
In der Eingabehilfe, die man in der Systemsteuerung findet, gibt es einen Reiter „Anzeige“. Hier findet man ein Kontrollkästchen mit der Beschriftung „Kontrast aktivieren“. Klickt man es an und aktiviert rechts unten den Schalter „Übernehmen“ wird der Kontrastmodus aktiviert. Die Aktivierung dauert ein bisschen. Nach und nach wird der Hintergrund Pech schwarz und überall erscheint eine weiße Schrift.Dieser Kontrastmodus darf durch eine Software nicht verändert oder verhindert werden.


Punkt 3: Bereitstellen eines dokumentierten Tastaturzugriffs auf alle Features

Erklärung:
Wie oben schon erwähnt, benutzen Menschen die blind oder sehbehindert sind, eher die Tastatur wie die Maus. Deswegen sollten alle Programmfunktionen auch über Tastatur erreichbar sein und die entsprechenden Tastenkürzel sollten in der Programmhilfe dokumentiert sein.


Punkt 4: Visuelle und programmgesteuerte Anzeige der Position des Tastaturfokus

Erklärung:
Für Menschen die hauptsächlich oder ausschließlich mit der Tastatur arbeiten ist es wichtig, schnell zu erkennen wo der Tastaturfokus ist. Aus diesem Grund muss der Tastaturfokus visuell angezeigt und erkennbar sein.


Punkt 5: Vermeiden der Übermittlung wichtiger Informationen allein per Audioausgabe

Erklärung:
Im Artikel weiter oben wurde es erwähnt, dass es Menschen gibt die gehörlos sind. Wenn wichtige Informationen nur per Audioausgabe zur Verfügung stehen, bekommen gehörlose Menschen die Informationen nicht mit. Deswegen sollten Informationen die per Audioausgabe zur Verfügung stehen auch in visueller Form angeboten werden. Ein Mail-Programm, welches dem Anwender nur über Sprache mitteilt, dass er neue Mails hat, wäre für gehörlose Menschen unbrauchbar.

Wenn diese 5 Punkte bei einer Standardsoftware erfüllt sind ist, laut Microsoft, eine Software barrierefrei.