Dieser Prüfschritt ist bei offener Funktionalität immer anwendbar.

Wie wird geprüft

Menschen mit visuellen Einschränkungen sollen automatisch über Ereignisse benachrichtigt werden, die außerhalb des aktuellen Fokus und ohne unmittelbare Veranlassung geschehen, wie etwa das Erscheinen von Systemmeldungen, die automatische Aktualisierung von Inhalten, etc.

Benutzer müssen nicht über Änderungen benachrichtigt werden, die durch ihre explizite Aktion geschehen und sich bei sequenzieller Abarbeitung nahe unterhalb ihrer aktuellen Position befinden.

Wenn Apps Statusmeldungen erzeugen, etwa wenn ein Produkt in einen Warenkorb gelegt wurde, ein Formular beim Abschicken eine Fehlermeldung oder eine Bestätigungsmeldung erzeugt, müssen visuell eingeblendete Statusmeldungen über geeignete Rollen oder Eigenschaften verfügen, um damit programmatisch, also auch für nicht-visuelle Benutzer, ermittelbar zu sein. Es kann im mobilen Applikationsumfeld nützlich sein, den Fokus bei Erscheinen der Statusmeldung automatisch auf die Meldung/den Alert zu setzen, damit einerseits der Screenreader die Meldung direkt auslesen kann, andererseits damit der User auch volle Unterstützung für seine Orientierung erhält. Der Hinweis/der Alert soll einen aussagekräftigen Titel enthalten und als Hinweis/Alert identifizierbar sein. Hinweise sollen nicht (bspw. via Countdown) automatisiert wieder ausgeblendet werden.

Beobachten Sie die durch die Arbeitsschritte des Testszenarios hervorgerufenen Änderungen, wie geänderte Darstellung, geänderte Inhalte und das Erscheinen von Meldungen aller Art. Erhalten derartige Änderungen den Fokus und werden alle Änderungen angemessen vom Screenreader wiedergegeben?

Ggf. ergänzen Sie das Szenario um Gelegenheiten zur Überprüfung von Meldungen, z. B. indem Sie den Empfang einer E-Mail provozieren, oder den Dark Mode des mobilen Endgeräts entsprechend automatisiert anschalten lassen.

Sofern es keine automatische Rückmeldung gibt, prüfen Sie, ob die Meldung visuell identifiziert werden kann, und ob sie per Wischnavigation links/rechts erreicht werden kann.

Sofern es keine Rückmeldungen gibt prüfen Sie, ob der Screenreader in den Ausführlichkeitseinstellungen korrekt konfiguriert ist und wiederholen Sie ggf. die Prüfung.

Beispiele

  • Nach dem Klick auf „In den Warenkorb legen“ bei einem Artikel erscheint die visuelle Meldung, dass der Artikel erfolgreich hinzugefügt wurde. Der Fokus muss automatisch auf diesen Hinweis gesetzt werden, der Screenreader muss die Meldung proaktiv ausgeben.
  • Nach dem Klick auf „Hinzufügen zur Merkliste“ erscheint die visuelle Meldung, dass das Produkt der Merkliste hinzugefügt wurde. Der Fokus muss automatisch auf diesen Hinweis gesetzt werden, der Screenreader muss die Meldung proaktiv ausgeben.
  • Bei falschem Befüllen von Formularfeldern erscheint die visuelle Meldung, dass x Felder nicht korrekt gefüllt sind. Der Screenreader muss die Meldung proaktiv ausgeben
  • Nach dem Abschicken eines Formulars erscheint die visuelle Meldung „Erfolgreich abgeschickt“. Der Fokus muss automatisch auf diesen Hinweis gesetzt werden, der Screenreader muss die Meldung proaktiv ausgeben.
  • Nach Ausführen einer Suche und anschließender Filterung der Ergebnisse werden x Suchergebnisse gefunden. Der Screenreader muss hierüber proaktiv informieren.
  • Nach Aufruf einer Seite erscheint ein Ladebalken, der über den Ladeprozess informiert. Der Screenreader muss über das Laden und den Fortschritt proaktiv informieren.
  • Bei Änderung des Punktestands (bspw. bei Deutschland Card, Payback, etc.) muss der Screenreader proaktiv über den neuen Punktestand informieren.

Erfüllt

  • Ein Formular blendet zusätzliche Eingabefelder ein, nachdem ein Auswahlschalter ausgewählt wurde. Die neuen Eingabefelder erscheinen unterhalb des Auswahlschalters, der Fokus bleibt bei den Auswahlschaltern stehen. Der Screenreader sagt „[Name der Option] ausgewählt“ und gibt nicht die neu erschienenen Bedienelemente aus.
  • Nach fehlerhaftem Ausfüllen von Formularfeldern erscheint gleich oberhalb des Eingabefeldes „fehlerhafte Eingabe“. Der Screenreader erkennt und meldet die Nachricht.
  • Nach Absenden eines korrekt ausgefüllten Formulars erscheint ein zusätzlicher Text (bspw. „Formular erfolgreich versendet“,) welcher vom Screenreader auch angekündigt wird.

Fehler

  • Ein Formular blendet zusätzliche Eingabefelder ein, nachdem ein Auswahlschalter ausgewählt wurde. Die neuen Eingabefelder erscheinen oberhalb des Auswahlschalters, wo sie bei kleinem Bildausschnitt und sequentieller Bedienung nicht wahrgenommen werden.
  • Eine Systemmeldung erscheint, aber der Screenreader gibt zunächst eine große Menge anderer Informationen aus, die der Benutzer abbricht, so dass er die Systemmeldung nicht bemerkt.
  • In einem Chatprogramm wird beim Erscheinen neuer Beiträge der gesamte Inhalt vorgelesen. Richtig wäre, nur den neu erschienenen Beitrag vorzulesen.
  • In einer Bestellfunktion wählt der Benutzer die gewünschten Produkte durch ein Kontrollkästchen aus und fügt dann alle ausgewählten Produkte durch eine Taste zum Warenkorb hinzu. Der Screenreader meldet die Änderung im Warenkorb, indem er den vollständigen Inhalt aller hinzugefügten Produktbeschreibungen vorliest. Die Art der vollzogenen Aktion wird nicht quittiert. Eine sinnvolle Rückmeldung wäre etwa die Benachrichtigung „xx Produkte zum Warenkorb hinzugefügt“.
  • Der Screenreader liest die Ankündigung nicht vor oder liest zusätzlich angezeigte Texte, wie „5 Fehler auf der Seite“ bei fehlerhaft ausgefüllten Daten nicht vor.
  • Eine Sanduhr oder ein Fortschrittsbalken zeigt, dass ein Prozess noch geladen wird. Der Screenreader meldet nicht, dass der Prozess in Bearbeitung ist.

Bewertung

Wenn die Rückmeldung durch zusätzliche Navigation gesucht werden muss, so ist dies möglicherweise schon eine Einschränkung. Dies ist im Kontext zu bewerten. Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.

Anforderung (Beschreibung)

Offene Funktionalität

Bei offener Funktionalität sollen visuell eingeblendete Statusmeldungen programmatisch ermittelbar, mit geeigneten Rollen oder Eigenschaften ausgezeichnet und damit für Benutzer assistiver Technologien ermittelbar sein.

Geschlossene Funktionalität

Bei geschlossener Funktionalität ist der Prüfschritt nicht anwendbar.

Warum wird das geprüft?

Statusmeldungen sind relevante Rückmeldungen, die Benutzer fortlaufend bei der Bedienung der APP erhalten, und zwar über alle von ihnen vorgenommenen Änderungen hinweg, einschließlich der bearbeiteten Inhalte, der vorgenommenen Selektionen und dem Status von Bedienelementen und Anzeigen. Rückmeldungen und Benachrichtigungen sollen für die Benutzerinteraktion relevant sein und Benutzer nicht stören.

Kontextänderungen sind neue Inhalte auf der Seite, die Benutzer unterbrechen, indem sie den Fokus versetzen. Kontextänderungen werden von assistiven Technologien durch den Fokuserhalt bereits wahrgenommen und sind deshalb nicht Bestandteil dieses Prüfschritts.

Eine barrierefreie Statusmeldung erfüllt folgende Kriterien:

  • Benachrichtigt Benutzer über den Erfolg oder die Ergebnisse einer Aktion, den Wartezustand einer APP, den Fortschritt eines Prozesses oder über das Vorhandensein von Fehlern.
  • Erzeugt keine Kontextänderung.

Keine Statusmeldungen sind:

  • Die gesamte Liste aller Suchergebnisse. Dagegen ist der Text „320 Suchergebnisse“ eine Statusmeldung, wenn sie z. B. nach der Aktivierung eines Filters erscheint oder als zusätzliche Rückmeldung zu einer Suche, z. B. „18 gefundene Elemente“ oder „Keine Ergebnisse gefunden“.
  • Eine Fehlermeldung wird in einem Dialogfenster angezeigt. Da das Dialogfenster den Fokus erhält oder sogar eine Benutzeraktion erfordert, bedeutet dies eine Kontextänderung und ist keine Statusmeldung.
  • Inhalt wird angezeigt oder ausgeblendet, wenn ein Benutzer mit einem Formularfeld interagiert, z. B. durch Ein-/Ausklappen eines Menüs, einer Baumstruktur oder einer Auswahlliste oder wenn eine Registerkarte ausgewählt wird. Keine dieser Änderungen entspricht der Definition der Statusmeldung.

Statusmeldung:

  • Eine zusätzliche Rückmeldung zur Suche, wie „18 gefundene Elemente“ oder „Keine Ergebnisse gefunden“.

Das Ziel dieses Erfolgskriteriums ist nicht das Programmieren vieler Statusmeldungen zu erzwingen. Ziel ist es, wenn Statusmeldungen vorhanden sind, diese für assistive Technologien zur Verfügung zu stellen.

Einordnung (Abgrenzung)

Die generelle Behandlung von Bewegung und dynamischen Änderungen, z. B. das Ausstellen von störenden Änderungen, ist in den Prüfschritten „11.2.3.1 Verzicht auf Flackern“ und „11.2.2.2 Bewegte Inhalte abschaltbar“ beschrieben.

Änderungen, die durch einen mitgeführten Fokus auf sich aufmerksam machen, werden im Prüfschritt „11.1.3.2 Sinnvolle Reihenfolge“ behandelt. Änderungen, die durch bloße Navigationsbewegungen des Benutzers entstehen, werden im Prüfschritt „11.3.2.1 Kontextänderung bei Fokus“ und „11.3.2.2 Keine unerwartete Kontextänderung“ behandelt.

Verweise (Referenzen)

  • EN 301549 v3.2.1 Kapitel 11.4.1.2 Name, role, value
  • EN 301549 v3.2.1 Kapitel 11.4.1.3 Status messages
  • EN 301549 v3.2.1 Kapitel 11.5.2.15 Change notification
  • WCAG v2.1 Kapitel 4.1.2 Name, role, value
  • WCAG v2.1 Kapitel 4.1.3 Status messages
  • ISO9241-171 „Leitlinien für Zugänglichkeit von Software“ 8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen
  • WAI-ARIA Authoring Practices 1.1 Kapitel 6.2 Implementing Live Regions