Jetzt Test anfragen
Jetzt Test anfragen
zum vorherigen Prüfschritt

Prüfschritt 11.4.1.2 Name, Rolle, Wert

zum nächsten Prüfschritt

Was wird geprüft?

Alle Bedienelemente einer App (also etwa Tasten, oder Formularelemente wie Checkboxen oder Eingabefelder) sollen semantische Informationen (Name, Rolle, ggf. Wert) programmatisch bereitstellen. Dies ermöglicht Hilfsmitteln wie Screenreadern, die Bedeutung und Funktion der Elemente zu kommunizieren. Nutzende können auf diese Weise die Elemente verstehen und bedienen. Bei nativen Elementen, also solchen, die mit den Standardelementen der Entwicklungsumgebungen umgesetzt sind, ist dies in der Regel ohne weiteres Zutun gegeben.

Werden Bedienelemente selbst erstellt (das heißt, es werden keine Standardelemente verwendet), müssen semantische Informationen wie Name, Rolle und Wert gegebenenfalls explizit definiert werden, damit diese an Hilfsmittel übergeben und in der Folge den Nutzenden ausgegeben werden.

Bei Apps wird dazu die Accessibility-Schnittstelle des jeweiligen Betriebssystems genutzt.

Warum wird das geprüft?

Für sehende Nutzende ist die Bedeutung von Bedienelementen in der Regel intuitiv verständlich, besonders, wenn sie konventionell umgesetzt sind und die Bedeutung sich damit aus der Erfahrung ähnlicher Elemente erschließt. Beispiele wären etwa ein Menü-Taste aus drei horizontalen Strichen (das sogenannte "Hamburger"-Icon) oder ein Lupen-Icon zum Auslösen einer Suche. Bei vielen Tasten und Eingabefeldern macht die Beschriftung das Element verständlich.

Menschen, die eine Webseite nicht-visuell nutzen, sind darauf angewiesen, dass Informationen zur Bedeutung eines Elements (Name, Rolle und ggf. Wert) auf einer abstrakten Ebene zur Verfügung stehen und assistive Technologien diese nutzen können. Man bezeichnet das auch als programmatische Ermittelbarkeit. Wenn ein Element, etwa ein grafischer Menü-Schalter für die Navigation, erreicht wird, sollte z.B. an Screenreader-Nutzende ausgegeben werden: "Navigation, Taste, reduziert". "Navigation" ist der hinterlegte Name, "Taste" die Rolle, und "reduziert" der Wert bzw. Zustand. Nutzende wissen dann, dass die Aktivierung dieses Elements ein Navigation einblenden wird (der Zustand der Taste ändert sich dadurch auf "erweitert").

Wenn Bedienelemente mit den von der Entwicklungsumgebung bereitgestellten Standard-Schnittstellen-Elementen umgesetzt werden, sind Rollen und Zustände in der Regel ohne weiteres Zutun programmatisch verfügbar. So sollten in iOS etwa Textfelder über das Standardelement UITextField umgesetzt werden und Tasten als UIButton.

Werden keine Standardelemente genutzt und die Bedienelemente selbst gebaut (etwa eine Grafik wird als Schalter bzw. Taste eingesetzt), gibt es je nach Plattform geeignete Wege, um Namen, Rollen (die Art des Bedienelements) und Werte bzw. typisches Verhalten des Elements programmatisch zu setzen. Wenn das geschieht, ist die Semantik auch bei nicht-visueller Nutzung (beispielsweise beim Einsatz des systemseitigen Screenreaders) verfügbar. Bei IOS dienen zur Hinterlegung eines Namens das Attribut AccessibilityLabel und zur Definition der Rolle und des Zustandes die Accessibility Traits. Bei Android leistet dies das contentDescription-Attribut.

Wie wird geprüft?

1. Anwendbarkeit des Prüfschritts

Der Prüfschritt ist immer anwendbar, wenn die App Bedienelemente einsetzt. Aus Sicht der prüfenden Person ist nicht immer zu erkennen, ob Standardelemente der Entwicklungsumgebungen verwendet werden (und damit quasi von Haus aus zugänglich sind) oder von Entwicklerinnen und Entwicklern selbst definiert wurden. Eine Sichtprüfung reicht deshalb nicht aus. Bedienelemente müssen mit dem Screenreader fokussiert und aktiviert werden, um festzustellen, ob die passende Namen, Rollen und Werte vom Screenreader ausgegeben und auch Zustandsänderungen richtig kommuniziert werden.

2. Prüfung

Für eine Prüfung mit VoiceOver / iOS müssen die AI/OCR-Erkennungsfunktionen ausgeschaltet sein (siehe "3. Hinweise").

  1. App mit zu prüfender Ansicht öffnen.

  2. Screenreader starten und Fokus mit Hilfe der Wischgeste auf jedes interaktive Element setzen.

  3. Prüfen, ob der Name, wo möglich die Rolle, und wo vorhanden der Wert des Bedienelements vom Screenreader korrekt ausgegeben werden (siehe auch "3. Hinweise").

  4. Gegebenenfalls prüfen, ob der geänderte Wert des Elements (Zustand) nach Eingabe korrekt ausgegeben wird.

3. Hinweise

Der Name identifiziert und bezeichnet ein Element näher. Nutzende von Spracheingabe-Software können beispielsweise eine Schaltfläche mit Hilfe des zugänglichen Namens (der Beschriftung) gezielt ansprechen und bedienen. Ein Screenreader gibt den zugänglichen Namen aus, wenn das Element fokussiert wird. Er ist oft gleichlautend mit der sichtbaren Beschriftung (bzw. dem Label) des Bedienelements, z.B. "Nachname" für ein Eingabefeld.

Beispiele für Rollen sind u.a. "Taste" bzw. "Schalter" oder "Schaltfläche", "Eingabefeld" bzw. "Bearbeitungsfeld", "Suchfeld", "Ausklappliste", und "Markierungsfeld" bzw. "Umschalttaste".

Verglichen mit dem Web ist die Anzahl der verfügbaren Rollen in nativen Apps geringer. Nicht jedes interaktive Element verlangt zwingend die Ausgabe einer Rolle. Bei korrekter Nutzung nativer Elemente (z.B. item in Android) werden jedoch bei aktiviertem Screenreader automatisch Hinweise zur Aktivierung ausgegeben (z.B. "zum Auswählen doppeltippen") - wenn "Nutzungshinweise vorlesen" in den TalkBack-Einstellungen unter "Ausführlichkeit" aktiviert ist.

Der Wert beschreibt z.B. den Inhalt des Bedienelements, z.B. "Müller" bei einem Eingabefeld für Nachnamen. Er vermittelt aber auch den Zustand eines Elements (sofern es unterschiedliche Zustände haben kann), z.B. "ausgewählt" für ein ausgewählten Listeneintrag oder eine angekreuzte Checkbox.

Einstellungen für die Prüfung mit VoiceOver / iOS

Die AI/OCR-Erkennungsfunktionen von VoiceOver müssen ausgeschaltet sein:

  • iOS 14+: Einstellungen > Bedienungshilfen > VoiceOver > VoiceOver-Erkennung. (Diese Funktion wird nur seit iPhone XS/XR-Modellen unterstützt).

  • iOS 13: Einstellungen > Bedienungshilfen > VoiceOver > Verbosität > Sprechen erkannt > Sprechen von erkanntem Text und Bildern.

4. Bewertung

Nicht erfüllt:

Wichtige Bedienelemente sind mit mit benutzerdefinierten Bedienelementen (Custom Controls) umgesetzt, auf eine Nachbildung der Semantik für die Barrierefreiheitsschnittstellen des Systems wurde verzichtet. Name, Rolle bzw., wo vorhanden, Wert werden vom Screenreader nicht korrekt ausgegeben.

Quellen

Allgemein

iOS

Android

Einordnung des Prüfschritts

Abgrenzung von anderen Prüfschritten

In diesem Prüfschritt geht es nicht um die Bewertung der Tastaturbedienbarkeit von selbsterstellten Bedienelementen. Dies ist Gegenstand von Prüfschritt 11.2.1.1 "Tastaturbedienung".

Einordnung des Prüfschritts nach WCAG 2.1

Guideline

Success criterion

Techniques

General Techniques
Failures