Dieser Prüfschritt ist bei offener Funktionalität 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 wird besonders auf diejenigen Elemente geachtet, die in der bisherigen Prüfung auffällig geworden sind. Eine Auffälligkeit ist durch Benutzerinteraktion mit der APP 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:

  • 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 soll einer sichtbaren Beschriftung oder Identifizierung, 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 soll 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.

Falls kein Zugriff auf den Source-Code der APP besteht, kann dieser Prüfschritt nur manuell mittels Screenreader durchgeführt werden.

  • Alle Bedienelemente mit dem Screenreader untersuchen: Werden der Name, die Rolle und ggf. der Wert des Bedienelements vom Screenreader korrekt ausgegeben?
  • Der Name muss hierbei dem Namen des Bedienelements entsprechen und ist in aller Regel gleichlautend mit dem Label des Bedienelements.
  • Zu den Rollen gehören sämtliche Formularfeld-Typen, Links, und alle weiteren Bedienelemente wie bspw. „Eingabefeld“, „Ausklappliste“, „Kontrollkästchen“ und „Taste“.
  • Der Wert beschreibt den Inhalt bzw. den aktuellen Status des Bedienelements, bspw. „Ein“ bei einer aktivierten Umschalttaste. Weitere Status-Werte sind z. B. „ausgewählt“ für einen aktivierten Auswahlschalter oder ein aktiviertes Kontrollkästchen.

Weitere Werte, die beachtet werden müssen, können sein:

  • Name des Elements, z. B. „Format übertragen“ oder „Dark Mode“.
  • Rolle, die Funktion des Elements, z. B. „Kontrollkästchen“ oder „Ausklappliste“ oder „Taste“
  • Übersetzung der Rolle in die Landessprache, z. B. „Taste“, „Listenelement“.
  • Interaktion, z. B. „markierbar, auswählbar, mehrfache Auswahl möglich“

Beispiele

Erfüllt

  • Auswahlschalter:
    „Auswahlschalter“, „ausgewählt/nicht ausgewählt. Zum Auswählen doppeltippen“, ‚Beschreibung/Funktion‘.
  • Kontrollkästchen:
    „Kontrollkästchen“, „aktiviert/nicht aktiviert. Zum Ändern doppeltippen“, ‚Beschreibung/Funktion‘.
  • Ausklappliste:
    „Ausklappliste, ‚Gruppenüberschrift/Bezeichnung‘, nicht erweitert, zum Ausklappen doppeltippen“;
    „Ausklappliste, ‚Gruppenüberschrift/Bezeichnung‘, erweitert, nichts markiert, zum Auswählen nach links oder rechts wischen, zum Auswählen doppeltippen“;
    „Ausklappliste, ‚Gruppenüberschrift/Bezeichnung‘, erweitert, markiert, ‚Position‘ von ‚Grenze‘, zum Auswählen nach links oder rechts wischen, zum auswählen doppeltippen“
  •  

Fehler

  • Die Sprachausgabe eines Screenreaders beschreibt ein Texteingabefeld als Kontrollfeld. Der Zustand eines Kontrollfeldes wird durch den Screenreader falsch wiedergegeben.
  • Der Zustand einer Ausklappliste oder eines Kombinationsfelds wird nicht wiedergegeben.
  • Die sichtbare Beschriftung einer Taste weicht von der Bezeichnung der Screenreaderausgabe ab.
  • Ein Schieberegler gibt den aktuell gewählten Wert nicht wieder.

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 im Feld Wert steht und der Wert des Elements sich dynamisch ändern kann (Formularfelder, Statusanzeigen), 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.

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.

Anforderung (Beschreibung)

Offene Funktionalität

Wenn die APP eine Benutzerschnittstelle bereitstellt, welche für assistive Technologien erreichbar ist, dann soll die korrekte Funktionalität der Elemente der APP 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 Benutzer assistiver Technologien ermittelbar. Daher ist dieser Prüfschritt für offene Funktionalität immer anwendbar.

Geschlossene Funktionalität

Bei APPs mit geschlossener Funktionalität, die eine Benutzerschnittstelle bereitstellen, welche für sämtliche assistive Technologien geschlossen ist, kann 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 somit nicht anwendbar.

Warum wird das geprüft?

Standard-Benutzerschnittstellen-Komponenten auf den meisten barrierefreiheits-unterstützten Plattformen erfüllen dieses Erfolgskriterium bereits, wenn sie entsprechend der Spezifikation verwendet werden. Diese Elemente, 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ößerungsfunktionalität und Spracheingabefunktionalität, 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.

Je vollständiger eine APP die Accessibility-Schnittstelle informiert, desto einfacher kann sie für die Benutzung mit assistiven Technologien verfügbar gemacht werden.

Verweise (Referenzen)

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