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

Wie wird geprüft

Menschen mit visuellen Einschränkungen sollen ü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, z.B. am unteren Rand des Fensters, etc. Nutzerinnen und Nutzer müssen nicht über Änderungen benachrichtigt werden, die durch ihre explizite Aktion geschehen und sich bei sequentieller Abarbeitung nahe unterhalb ihrer aktuellen Position befinden.

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

Ggf. ergänzen Sie das Szenario um Gelegenheiten zur Überprüfung von Meldungen, z.B. indem Sie z.B. den Empfang einer E-Mail provozieren.

Sofern es keine Rückmeldung gibt, prüfen Sie, ob die Meldung durch eine Bewegung der Pfeiltasten (ein Tastendruck in jede Richtung) gefunden 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

  • Bei der Auswahl von Einträgen in einer Mailbox erhält der Benutzer die Rückmeldung „E-Mail ausgewählt“ oder „E-Mail wird angezeigt.
  • In einer Dokumentensuche erscheint in einer Meldungszeile die Warnung, dass zunächst die zu durchsuchenden Datenbanken ausgewählt werden müssen, bevor die Suchanfrage beantwortet werden kann. Der Screenreader liest die Meldung sofort vor.
  • Während der Bedienung einer Anwendung erscheint eine Sprechblase, die das Eintreffen einer neuen E-Mail bekannt gibt. Der Screenreader liest die Sprechblase vor, sobald die aktuelle Benutzeraktion abgeschlossen ist.
  • Fehler: 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.
  • Fehler: In einem Chatprogramm wird beim Erscheinen neuer Beiträge der gesamte Inhalt vorgelesen. Richtig wäre, nur den neu erschienenen Beitrag vorzulesen.
  • Kein Fehler: Ein Formular blendet zusätzliche Eingabefelder ein, nachdem eine Optionsschaltfläche ausgewählt wurde. Die neuen Eingabefelder erscheinen unterhalb der Optionsschaltflächen, der Tastaturfokus bleibt bei den Optionsschaltflächen stehen. Der Screenreader sagt „[Name der Option] ausgewählt“ und gibt nicht die neu erschienenen Bedienelemente aus. Fehler: Wie zuvor, aber die neuen Eingabefelder erscheinen oberhalb der Optionsschaltflächen, wo sie bei kleinem Bildausschnitt und sequentieller Bedienung nicht wahrgenommen werden.
  • Fehler: 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 einen Funktionsbutton 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“.
  • 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 z.B „Formular erfolgreich versendet“, welcher vom Screenreader auch angekündigt wird.
  • Fehler: 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.
  • Fehler: 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 einen zusätzlichen Tastendruck 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)

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

Wenn die Anwendung auf einer Auszeichnungssprache basiert, sollen visuell eingeblendete Statusmeldungen programmatisch ermittelbar sein, mit geeigneten Rollen oder Eigenschaften ausgezeichnet sein und damit für Nutzer assistiver Technologien ermittelbar. Dabei sollen Statusmeldungen den Fokus nicht versetzen.

Nicht-Web-Software mit geschlossener Funktionalität

Bei nicht-Web-Software mit 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 Anwendung 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, indem sie z.B. den Fokus versetzen.

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 barriefreie Statusmeldung erfüllt folgende Kriterien:

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

Keine Statusmeldung 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, einer Auswahlliste oder eines Akkordeons 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 2.3.1 „Verzicht auf Flackern“ und 2.2.2  „Bewegte Inhalte abschaltbar“ beschrieben.

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

Verweise (Referenzen)

  • EN 301549 v3.1.1 Kap. 11.4.1.3 Status messages
  • WCAG v2.1 v.3.1.1 Kap. 4.1.3 Status messages
  • ISO 9241-171 „Leitlinien für Zugänglichkeit von Software“  8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen
  • Sonstige
    • WAI-ARIA Authoring Practices 1.1 Kapitel 6.2 Implementing Live Regions