7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Objektinformationen zu Bedienelementen und Anzeigen werden über die Accessibility-Schnittstelle des Betriebssystems für Hilfstechniken verfügbar gemacht.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Windows bietet die Schnittstellen MSAA (Microsoft Active Accessibility) und UIA (User Interface Automation) für die Kommunikation mit unterstützender Technik an. Weitere bekannte Accessibility-Schnittstellen sind IAccessible2 und Java Access Bridge. Die Anwendung stellt in einer dieser Schnittstellen u.a. die folgenden Objektinformationen bereit:

• Name des Elements. Beispiel: der Name eines grafischen Buttons lautet „Kontakt“. 
• Rolle bzw. Funktion des Elements. Beispiel: ein Button hat die Rolle „Button“ oder „Schaltfläche“.
• Wert des Elements. Beispiele: Der angezeigte Inhalt eines Textfeldes lautet „Hochofenstraße“. Der Zustand einer Statusanzeige lautet „Internetzugriff hergestellt“.
• Informationen zum Status des Bedienelements wie „verfügbar“, „markiert“, „fokussiert“.
• Label-Beziehungen, d.h. ein Element wird durch den Wert eines benachbarten Elements benannt. Beispiel: Ein Eingabefeld hat keinen Namen, aber der benachbarte Text „Straße“ ist als Label für das Eingabefeld gekennzeichnet.
• Informationen zur Einordnung des Elements in die Objekthierarchie der Anwendung: Eltern-, Geschwister- und Kind-Elemente.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Die Bereitstellung von Objektinformationen über eine standardisierte Schnittstelle ermöglicht die Kompatibilität mit assistierenden Techniken wie Screenreader, Vergrößerungssoftware und Spracheingabesoftware, die von Menschen mit Behinderungen benutzt werden. Anwendungselemente, die mit Standardroutinen des Betriebssystems erzeugt wurden, übermitteln ihre Objektinformationen defaultmäßig an die Accessibility-Schnittstelle. Sie benötigen ggf. noch einen Namen, um ausreichend deklariert zu sein. Dagegen müssen neuartige oder individuell entwickelte Elemente mit allen Merkmalen gegenüber der Accessibility-Schnittstelle deklariert werden. Wenn dies nicht geschieht, müssen die Hersteller von Hilfstechniken die Objektinformationen aus anderen Quellen erschließen, wie etwa dem DOM (Document Object Model) der Anwendung oder den Ein-/Ausgaberoutinen des Betriebssystems, was sehr aufwändig ist und nicht immer gelingt. Je vollständiger eine Anwendung die Accessibility-Schnittstelle informiert, desto einfacher kann sie für die Benutzung mit assistiven Technologien verfügbar gemacht werden.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Stellen Sie zunächst fest, ob die Anwendung mit JAVA programmiert ist oder die Schnittstelle IAccessible2 verwendet (siehe Herstellerfragebogen und Technische Prüfung). Für solche Anwendungen ist diese Prüfanleitung nicht geeignet. Für alle anderen Anwendungen gilt das Folgende:

Verwenden Sie das Tool Inspect (siehe Werkzeugliste), um zu überprüfen, ob die Anwendung ausreichende Objektinformationen an die Accessibility-Schnittstelle übergibt.

Untersuchen Sie diejenigen Bedienelemente und Anzeigen, die in der bisherigen Prüfung auffällig geworden sind, und zusätzlich für jeden Arbeitsschritt des Szenarios 2 weitere, zufällig gewählte UI-Elemente.

Öffnen Sie inspect.exe. Unter „Options“ aktivieren Sie mindestens die folgenden Einstellungen:

• UI Automation Mode – umfasst auch MSAA, hier als „Legacy“-Properties benannt
• Raw View
• SPI_SCREENREADER Flag
• Show Highlight Rectangle
• Watch Focus
• Watch Cursor
• Show Tree

Es gibt auch die Möglichkeit, sich wichtige Elemente direkt am zu prüfenden Element als Tooltipp anzeigen zu lassen. Darauf wird an dieser Stelle jedoch nicht eingegangen.

Zum Prüfen bewegen Sie den Mauszeiger oder den Tastaturfokus zum zu untersuchenden Element, oder wählen Sie das Element im Inspect-Tree aus. Stellen Sie zunächst fest, ob das Element einfach oder zusammengesetzt ist. Bei zusammengesetzten Elementen führen Sie die Untersuchung für jedes Einzelteil durch. Bei Unstimmigkeiten überprüfen Sie auch, ob das Element im fokussierten Zustand andere Properties hat als im nicht fokussierten Zustand.

Sobald sich ein Rahmen um das zu untersuchende Element gebildet hat, drücken Sie die Tastenkombination STRG+SHIFT+4, damit die Ergebnisliste der Property-Werte in die Zwischenablage kopiert wird. Zum Lesen fügen Sie den Inhalt der Zwischenablage in einen Editor ein. Dieses Vorgehen ist etwas umständlich, hilft aber gegen Instabilitäten im Umgang mit Inspect.

Untersuchen Sie die Property-Werte in der Ergebnisliste. Achten Sie insbesondere auf folgende Werte:

• Name oder LegacyIAccessible.Name - der Name des Elements, z.B. "Format übertragen".
• ControlType – die Rolle, die Funktion des Elements, z.B. „UIA_ButtonControlTypeId (0xC350)“
• LocalizedControlType - Übersetzung der Rolle in die Landessprache, z.B. "Schaltfläche".
• LegacyIAccessible.Role - MSAA-Rolle, z.B. „Schaltfläche (0x2B)“.
• Value.Value oder LegacyIAccessible.Value – Der Wert oder Inhalt des Elements, ist bei einer reinen Schaltfläche leer, also "".
• LegacyIAccessible.State – MSAA-Status, z.B. „markierbar,auswählbar,mehrfache Auswahl möglich (0x1300000)“
• IsEnabled - Verfügbar, kann die Werte "true" oder "false" annehmen.
• SelectionItem.IsSelected – Ausgewählt, kann die Werte "true" oder "false" annehmen.
• HasKeyboardFocus -  Fokussiert, kann die Werte "true" oder "false" annehmen.
• IsKeyboardFocusable – Fokussierbar, kann die Werte "true" oder "false" annehmen.
• Next, Previous – benachbarte Elemente
• Children – untergeordnete Elemente
• Ancestors – übergeordnete Elemente

Bitte beachten Sie:

• Der Name des Elements sollte einer sichtbaren Beschriftung, soweit vorhanden, entsprechen.
• Bei zusammengesetzten Elementen kann der Name auch in einem benachbarten, über- oder untergeordneten Element stehen, das zur selben Gruppe gehört.
• Der Name des Elements kann auch in einem anderen Feld wie Wert oder Hilfetext stehen; dies ist kein Mangel, soweit hieraus keine Widersprüche entstehen. Unproblematisch ist es, wenn der Name eines Buttons als Wert ausgegeben wird. Inakzeptabel dagegen ist es, wenn der Name eines Eingabefeldes oder einer Statusanzeige als Wert ausgegeben wird, denn damit wird die Wiedergabe des eingegebenen oder dynamisch veränderten Werts blockiert.
• Die Rolle des Elements sollte der in der praktischen Erprobung festgestellten Funktion entsprechen.
• Bei zusammengesetzten Elementen sind Name, Rolle und Status der Einzelteile nicht mehrdeutig oder widersprüchlich angegeben.
• Benachbarte Elemente (prev und next) werden, sofern sie eine Label-Beziehung beschreiben, konsistent verwendet.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Wenn sich kein Rahmen um das Element bildet, oder der Rahmen nicht der visuell wahrnehmbaren Begrenzung des Elements entspricht, so ist dies ein Mangel.

Wenn der Name des Elements nicht vorhanden ist, nicht der sichtbaren Beschriftung entspricht, verschiedene Namen in den Teilen eines zusammengesetzten Elements angegeben sind, verschiedene Namen im fokussierten und nicht fokussierten Zustand angegeben sind, so ist dies ein Mangel.

Wenn die Rolle des Elements unzutreffend angegeben ist, oder in den verschiedenen für die Rolle einsetzbaren Feldern widersprüchliche Angaben stehen, oder in den Teilen eines zusammengesetzten Elements widersprüchliche Rollen angegeben sind, oder im fokussierten und nicht fokussierten Zustand des Elements verschiedene Rollen angegeben sind, so ist dies ein Mangel.

Mängel in Name, Rolle und Begrenzung des Elements werden nach der Bedeutung des Elements für die Arbeitsaufgabe bewertet.

Alle weiteren Mängel werden als Einschränkung gewertet.

Für den Bericht an Entwickler notieren Sie das bemängelte Element bitte mit dem Klassen-Namen (ClassName).

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Die folgenden Informationen aus Inspect gehen in den Prüfschritt 4.10.2 „Zusätzliche kontextsensitive Hilfe“ ein:

• HelpText oder LegacyIAccessible.Help
• LegacyIAccessible.Description
• LegacyIAccessible.DefaultAction
• AccessKey oder LegacyIAccessible.KeyboardShortcut

Textattribute werden im Prüfschritt 4.06.1 „Wiedergabe von Textattributen“ überprüft.

Tabellen werden im Prüfschritt 4.08.1 „Orientierung in Tabellen“ überprüft.

Informationen über Änderungen an den Elementen einer Anwendung werden im Prüfschritt 4.09.1 „Benachrichtigung über Änderungen“ überprüft.

Fokusverfolgung wird im Prüfschritt 5.04.1 „Fokusverfolgung im Großbildsystem“ überprüft.

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

Zur Überprüfung der Rolle eines Elements wäre es hilfreich, ein Verzeichnis der in UIA gebräuchlichen Rollenbezeichnungen zu haben, eine entsprechende Referenz wird noch gesucht.

Die Verwendung des UIA-Attributs labelledby zur Kennzeichnung von Labelbeziehungen ist in der Anwendungsentwicklung bisher anscheinend nicht gebräuchlich. Diese Beobachtung braucht Verifizierung.

Prüftools für JAVA-Anwendungen und für die Schnittstelle IAccessible2 müssen noch benannt werden.

 

Referenzen

EN301549

11. 2.1.38 Name, Role, Value

11.3 Interoperability with assistive technology

WCAG

4.1.2 Name, Rolle, Wert

ISO9241-171

8.1.4 Namen für unterstützende Technik verfügbar machen

8.5. Kompatibilität mit unterstützender Technik