Dieser Prüfschritt ist immer anwendbar.

Wie wird geprüft

Bei allen Benutzerschnittstellen-Komponenten (einschließlich, aber nicht beschränkt auf: Formularelemente, Links, von Skripten generierte Komponenten) können Name und Rolle programmatisch ermittelt werden. Vom Benutzer festlegbare Zustände, Eigenschaften und Werte sowie deren Änderung soll auch programmatisch ermittelbar sein.

Zusätzlich zu den Bedienelementen oder Gruppen von Bedienelementen können Beschriftungen, Anweisungen, Meldungen und Anzeigen untersucht werden. Dabei achten Sie besonders auf diejenigen Elemente, die in der bisherigen Prüfung auffällig geworden sind. Eine Auffälligkeit ist durch Benutzerinteraktion mit der Anwendung festzustellen und macht sich häufig durch ein widersprüchliches oder fehlerhaftes Verhalten bemerkbar. In diesem Kontext sind Feststellungen aus den folgenden Prüfschritten zu beachten:

  • 2.1.1 Ohne Maus nutzbar
  • 1.3.2 Sinnvolle Reihenfolge
  • 1.1.1 Nicht-Text-Inhalte
  • 1.3.1 Info und Beziehungen
  • 5.2.5 Objektinformationen
  • 5.2.7 Werte
  • 5.2.16 Änderungen von Zuständen und Eigenschaften
  • 5.2.17 Änderungen von Werten und Text

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.
  • Die Rolle des Elements sollte der in der praktischen Erprobung festgestellten Funktion entsprechen.
  • Bei zusammengesetzten Elementen dürfen Name, Rolle und Status der Einzelteile nicht mehrdeutig oder widersprüchlich angegeben werden.
  • Benachbarte Elemente (prev und next) werden, sofern sie eine Label-Beziehung beschreiben, konsistent verwendet.

Verwenden Sie die das kostenlose Programm Accessibility Insights (https://accessibilityinsights.io/)  oder Inspect.exe (siehe Werkzeugliste), um zu überprüfen, ob die Anwendung ausreichende Objektinformationen an die Accessibility-Schnittstelle übergibt.

Mit Accessibility Insights können Sie die IAccessible Eigenschaften und Merkmale der Objekte oder der kompletten Seite ansehen. Mit einem automatischen Prüftool (FastPass) kann man die korrekte Funktionalität der Elemente anzeigen lassen und mögliche Fehler direkt untersuchen. Darüber hinaus kann man Tabstopps testen, den Kontrast prüfen oder Screenshots erstellen. Mit Inspect ist nur ein manuelles Prüfen der Objekte möglich.

Vorgehen „Accessibility Insights“:

Vergewissern Sie sich, dass die Registerkarte „Inspect“ (Strg+I) ausgewählt ist und sich ein Rahmen um das untersuchende Element gebildet hat. Mit der Default-Einstellung „Live-Inspect“ können relevante Property-Werte im rechten Seitenbereich eingesehen werden.

Alternativ kann eine Aufzeichnung der zu prüfenden Elemente mithilfe der Tastenkombination Shift+F7 gestartet werden. Im Folgenden werden alle fokussierten Elemente nacheinander aufgezeichnet, bis die Aufzeichnung mit einer erneuten Ausführung der Tastenkombination Shift+F7 beendet wird. Durch ein anklicken der einzelnen Events wird das fokussierte Element optisch hervorgehoben und die aufgezeichneten Property-Werte werden angezeigt. Dieses Vorgehen ist zielführend, wenn die gleichzeitige Bedienung von „Accessibility Insights“ und der Anwendung umständlich ist.

Für eine automatisierte Prüfung der Elemente oder der kompletten Seite fokussieren Sie das zu untersuchende Element, sodass sich ein Rahmen um dieses Element bildet. Mit Betätigung der Tastenkombination Shift+F8  oder des Test-Buttons wird das Element auf Unstimmigkeiten hinsichtlich der Property-Werte geprüft. Zusätzlich kann eine weitere Überprüfung der gefundenen Fehler im Reiter „Live-Inspect“ erfolgen.

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

  • Name oder LegacyIAccessiblePattern.Name – der Name des Elements, z.B. „Format übertragen“.
  • ControlType – die Rolle, die Funktion des Elements, z.B. „Checkbox“ oder „Button“
  • LocalizedControlType – Übersetzung der Rolle in die Landessprache, z.B. „Schaltfläche“, „Listenobjekt“. 
  • LegacyIAccessiblePattern.Role – MSAA-Rolle, z.B. „Schaltfläche“.
  • ValuePattern.Value oder LegacyIAccessiblePattern.Value – Der Wert oder Inhalt des Elements, ist bei einer reinen Schaltfläche leer, also „“. 
  • LegacyIAccessiblePattern.State – MSAA-Status, z.B. „markierbar, auswählbar, mehrfache Auswahl möglich (0x1300000)“
    • IsEnabled – Verfügbar, kann die Werte „true“ oder „false“ annehmen.
    • IsSelected – Element ausgewählt, kann die Werte „true“ oder false“ annehmen
    • ToggleState – Status eines Elements (z. b. Kontrollkästchen), kann die Werte „Togglestate_On“, „Togglestate_Off“ oder „ToggleState_Indeterminate“ annehmen 
    • ExpandCollapseState – Zustand eines Elements (z. b. Akkordeon ist ein- oder ausgeklappt), kann die werte „ExpandCollpaseState_Collapsed“ oder „ExpandCollpaseState_Expanded“ 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

Beispiele

  • Die Sprachausgabe eines Screenreaders beschreibt ein Texteingabefeld als Kontrollfeld. Hier sollte das Attribut ControlType, LocalizedControlType und LegacyIAccessible.Role geprüft werden
  • Der Zustand eines Kontrollfeldes wird durch den Screenreader falsch wiedergegeben. Es sollte unter Anderem das Attribut ToggleState kontrolliert werden.
  • Der Zustand einer Ausklappliste, Kombinationsfeld oder Akkordeon wird nicht wiedergegeben. Hier sollte ExpandCollapseState geprüft werden.
  • Die sichtbare Beschriftung einer Schaltfläche weicht von der Bezeichnung der Screenreaderausgabe ab. Es ist Name oder LegacyIAccessible.Name zu kontrollieren.
  • Ein Schieberegler gibt den aktuell gewählten Wert nicht wieder. Das Attribut Value ist zu prüfen.

Bewertung

  • 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 oder verschiedene Namen im fokussierten und nicht fokussierten Zustand angegeben sind, so ist dies ein Mangel.
  • Wenn der Name des Elements nicht im Feld Name, sondern in einem anderen Feld wie Wert oder Hilfetext steht und hieraus keine Widersprüche entstehen, so ist dies eine Einschränkung.
  • Wenn der Name des Elements im Feld Wert steht und der Wert des Elements sich dynamisch ändern kann (Formularfelder, Statusanzeigen), so ist dies ein Mangel.
  • Als Mängel zu bewerten sind:
    • wenn die Rolle des Elements unzutreffend angegeben ist
    • in den verschiedenen für die Rolle einsetzbaren Feldern widersprüchliche Angaben stehen
    • in den Teilen eines zusammengesetzten Elements widersprüchliche Rollen angegeben sind
    • im fokussierten und nicht fokussierten Zustand des Elements verschiedene Rollen angegeben sind

Alle Mängel, soweit nicht bereits gewichtet, werden nach der Bedeutung für die Arbeitsaufgabe bewertet. Für den Bericht an Entwickler erstellen Sie bitte einen Screenshot in „Accessibility Insights“ oder notieren Sie in „Inspect“ das bemängelte Element mit dem Klassen-Namen (ClassName).

Anforderung (Beschreibung)

Webbasierte Software und Nicht-Web-Software mit offener Funktionalität

Wenn die Anwendung eine Benutzerschnittstelle bereitstellt, welche für assistive Technologien erreichbar ist, dann soll die korrekte Funktionalität der Elemente der Anwendung und deren Zustände durch programmatische Ermittlung geprüft werden. Diese sollen mit geeigneten Namen, Rollen und Eigenschaften ausgezeichnet sein und sind damit für Nutzer assistiver Technologien ermittelbar.

Daher ist dieser Prüfschritt für offene Funktionalität immer anwendbar.

Nicht-Web-Software mit geschlossener Funktionalität

Bei nicht-Web-Software mit geschlossener Funktionalität, die eine Benutzerschnittstelle bereitstellt welche für sämtliche assistive Technologien geschlossen ist, muss sie das Erfolgskriterium „Name,Rolle,Wert“ nicht erfüllen, weil die programmatische Ermittelbarkeit nicht gegeben ist. Für geschlossene Funktionalität ist 4.1.2 laut EN 301 549 nicht anwendbar, weil programmatische Ermittelbarkeit dort nicht gegeben ist.

Warum wird das geprüft?

Dieses Erfolgskriterium ist hauptsächlich für Softwareentwickler gedacht, die benutzerdefinierte Schnittstellen-Komponenten entwickeln oder verwenden.

Standard-Benutzerschnittstellen-Komponenten auf den meisten barrierefreiheits-unterstützten Plattformen erfüllen dieses Erfolgskriterium bereits, wenn sie entsprechend der Spezifikation verwendet werden. Diese Anwendungselemente, die mit Standardroutinen erzeugt wurden, übermitteln ihre Objektinformationen in der Regel an die Accessibility-Schnittstelle. Sie benötigen ggf. noch einen Namen, um ausreichend deklariert zu sein. Die Bereitstellung von Objektinformationen über eine standardisierte Schnittstelle ermöglicht die Kompatibilität mit assistiven Technologien wie Screenreader, Vergrößerungssoftware und Spracheingabesoftware, die vorzugsweise von Menschen mit Behinderungen benutzt werden.     

Dagegen müssen neuartige oder individuell (durch Code oder Skript) 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 (Hilfstechniken) verfügbar gemacht werden.

Verweise (Referenzen)

  • EN 301549 v3.2.1 Kap.
    • Kap.11.4.1.2 Name, role, value
    • Kap. 11.5 Interoperability with assistive technology
  • WCAG v2.1 Kap. 4.1.2 Name, role, value
  • ISO9241-171 „Leitlinien für Zugänglichkeit von Software“
    • 8.1.4 Namen für unterstützende Technik verfügbar machen
    • 8.5. Kompatibilität mit unterstützender Technik
  • WCAG-Techniques