Dynamische Benachrichtigungen

Dieser Beitrag wurde gemeinsam von Chris McMeeking und Jennifer Dailey verfasst.

Der korrekte Umgang mit dynamischen Inhalten in Anwendungen kann schwierig sein und zu zahlreichen Verstößen gegen die Barrierefreiheit führen. Es ist wichtig zu wissen, welche Werkzeuge iOS für den Umgang mit dynamischen Inhalten bereitstellt. Dynamische Anwendungsinhalte lassen sich problemlos korrekt handhaben, solange Sie diese Werkzeuge verstehen und wissen, wie man sie einsetzt. In diesem Beitrag werden wir folgende Themen behandeln:

• Wann dynamische Benachrichtigungen verwendet werden sollten
• So implementieren Sie dynamische Benachrichtigungen
• Einige besonders hilfreiche Barrierefreiheitshinweise und ihre Anwendungsmöglichkeiten
• Eine ausführliche Erörterung eines Beispiels aus unserer Open-Source-Anwendung „ Deque University“ für iOS

Wann sollten dynamische Benachrichtigungen verwendet werden?

Wenn sehende Nutzer eine Anwendung verwenden, können sie sich visuell über Änderungen auf dem Bildschirm informieren. Nicht sehende Nutzer hingegen erhalten keine Informationen über diese kontextbezogenen Änderungen, es sei denn, die Entwickler achten besonders darauf, diese Änderungen zu kommunizieren. Es gibt viele Szenarien, in denen dynamische Benachrichtigungen für die Erstellung einer barrierefreien Anwendung unerlässlich sind. Ein gängiges Beispiel ist das Drücken einer Schaltfläche durch einen Nutzer. Wenn die Schaltfläche ein Element hinzufügt oder löscht (wie im folgenden Beispiel), sollte VoiceOver ansagen, was hinzugefügt oder gelöscht wurde.

Achten Sie jedoch darauf, nicht zu viele Benachrichtigungen hinzuzufügen! Es ist wichtig, ein gutes Gleichgewicht zu finden. Der Nutzer sollte benachrichtigt und auf dem Laufenden gehalten werden, aber nicht mit akustischen Benachrichtigungen überflutet werden. Zu viele Benachrichtigungen können störend wirken und die Barrierefreiheit der App beeinträchtigen.

Dynamische Benachrichtigungen implementieren

Um eine VoiceOver-Benachrichtigung hinzuzufügen, verwenden Sie einfach die folgende Codezeile in einem Funktionsaufruf:

[code language="objc"]
UIAccessibilityPostNotification(UIAccessibilityNotification, UIObject);
[/code]

wobei UIAccessibilityNotification ist eine der vielen aufgeführten Benachrichtigungen UIAccessibility-Protokollreferenz, und UIObject ist entweder ein UIView oder ein NSString. Jede UIAccessibility-Benachrichtigung dient einem anderen Zweck. Die am häufigsten verwendeten sind im Folgenden aufgeführt.

UIAccessibilityAnnouncementNotification

[code language="objc"]
UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification,
@"Dies laut vorlesen");
[/code]

„UIAccessibilityAnnouncementNotifications“ sind nützlich, wenn VoiceOver eine benutzerdefinierte Ansage vorlesen soll. Im obigen Beispiel würde die Benachrichtigung VoiceOver dazu veranlassen, die angegebene Zeichenfolge anzusagen. In der Praxis sollte diese Funktion sparsam eingesetzt werden und nur selten als Folge einer Benutzerinteraktion verwendet werden. Benachrichtigungen, die aus einer Benutzerinteraktion resultieren, sollten mithilfe der folgenden beiden Benachrichtigungstypen implementiert werden:

UIAccessibilityLayoutChangedNotification

[code language="objc"]
UIAccessibilityPostNotification(UIAccessibilityNotification, UIObject);
[/code]

„UIAccessibilityLayoutChangedNotifications“ sind nützlich, wenn ein Element hinzugefügt oder geändert wurde und den Fokus erhalten soll. Dies wird in der Regel bei Änderungen verwendet, die nur einen kleinen Teil des Bildschirms einnehmen. Ein Beispiel hierfür ist das Hinzufügen von Inhalten als Ergebnis einer Formularaktion. Diese Benachrichtigung akzeptiert zwei Arten von Argumenten: ein UIObject oder ein NSString.

[code language="objc"]
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification,
@"Dies laut vorlesen");
[/code]

Diese Version verhält sich genau wie die UIAccessibilityAnnouncementNotification, das die angegebene Zeichenfolge ansagt. Die Anwendungsfälle hierfür sind im Grunde dieselben wie bei denen der UIAccessibilityAnnouncementNotification. Es gibt keinen funktionalen Unterschied zwischen den beiden, auch wenn eine Variante stilistisch besser geeignet sein könnte. Man könnte zum Beispiel UIAccessibilityAnnouncementNotifications um verschiedene Ankündigungen zu veröffentlichen, während man UIAccessibilityLayoutChangedNotifications um Ankündigungen gezielt dann zu veröffentlichen, wenn diese Ankündigungen dadurch entstehen, dass der aktuellen Ansicht dynamische Inhalte hinzugefügt werden.

[code language="objc"]
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification,
aUIElementObject);
[/code]

Der obige Code bewirkt, dass VoiceOver den Fokus auf das angegebene Benutzeroberflächenelement verlagert und dessen Barrierefreiheitsbezeichnung ansagt. Dies ist beispielsweise für benutzerdefinierte modale Dialogfelder nützlich. Hinweis: Um die Barrierefreiheit zu gewährleisten, muss die Verlagerung des Fokus innerhalb einer Anwendung sorgfältig gehandhabt werden. Ein übermäßiger Einsatz dieser Vorgehensweise kann bei Nutzern von Bildschirmleseprogrammen leicht zu Frustrationen führen.

UIAccessibilityScreenChangedNotification

UIAccessibilityScreenChangedNotification ist ähnlich wie UIAccessibilityLayoutChangedNotification, wobei es zwei wichtige Unterschiede gibt. Und zwar wird jede Variante der Bildschirmwechsel-Benachrichtigung von einem leisen „Piep-Piep“-Ton begleitet, der dem Benutzer signalisiert, dass er sich nun in einem anderen Fenster befindet. Das Verhalten ist im Großen und Ganzen dasselbe, abgesehen davon, dass es eine zusätzliche nützliche Variante gibt, nämlich die Übergabe eines nil-Arguments.

[code language="objc"]
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
[/code]

Wenn Sie kein zweites Argument angeben, gibt VoiceOver den „Beep-Boop“-Ton aus, der eine Bildschirmänderung signalisiert, verschiebt den Fokus auf das erste Barrierefreiheitselement auf dem Bildschirm und liest dessen Barrierefreiheitsbezeichnung vor. Dies entspricht genau dem Verhalten, das Sie erhalten würden, wenn Sie Folgendes tun würden.

[code language="objc"]
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification,
firstAccessibilityElement);
[/code]

In der Praxis wird das iOS-Framework in den meisten Fällen, in denen Sie versucht wären, diese Benachrichtigung zu verwenden, die richtige Vorgehensweise für Sie übernehmen. Die Fälle, in denen Sie dies selbst tun möchten, sind sehr begrenzt. Ein Beispiel wäre der Fall einer benutzerdefinierten Navigation mit Registerkarten. Wenn Sie zu einer neuen Registerkarte wechseln, ändert sich nicht der gesamte Bildschirm, da Ihre Registerkartenleiste weiterhin vorhanden ist und derselbe ViewController weiterhin angezeigt wird. Die stattgefundene Interaktion ist jedoch eine, die ein Benutzer normalerweise damit in Verbindung bringen würde, dass sich der „Bildschirm“ geändert hat; da Sie sich jedoch im selben ViewController befinden, führt iOS die entsprechende Aktion nicht automatisch aus. In diesem Fall müssen Sie diese Benachrichtigung senden, um das korrekte Verhalten zu erzielen – insbesondere den „Beep-Boop“-Ton, der den Nutzer darüber informiert, dass sich der Bildschirm geändert hat, und um den Fokus auf das erste Barrierefreiheitselement zu verlagern. ODER, wenn sich Ihre Registerleiste oben befindet, kann es sinnvoll sein, ein Argument ungleich nil anzugeben, nämlich das erste Barrierefreiheitselement, das NICHT Teil Ihrer Registerleiste ist.

Beispiel für dynamische Benachrichtigungen

Diese Anleitung bezieht sich auf unsere Open-Source-App „ Deque University“ für iOS. Bitte installieren Sie diese App auf Ihrem Gerät und aktivieren Sie VoiceOver. Sie finden „Deque University“ für iOS auch im App Store, allerdings kann die dort veröffentlichte Version hinter der im Open-Source-Repository genannten Version zurückliegen. Die Open-Source-App dient als bevorzugte Referenz. Bevor Sie fortfahren, suchen Sie im Hauptmenü den Eintrag „Dynamic Notifications“ und wechseln Sie zur Registerkarte „Fixed“. Die folgende Anleitung bezieht sich auf diese Ansicht.

Für einen sehenden Nutzer ist diese Benutzeroberfläche intuitiv – durch Tippen auf „Speichern“ wird ein Kontakt gespeichert, durch Tippen auf „Kontakte löschen“ wird der gesamte Inhalt der Liste gelöscht. Ist das Textfeld nicht leer und wird „Speichern“ gedrückt, kann ein sehender Nutzer sehen, dass der Name erfolgreich gespeichert wurde; dasselbe gilt für „Kontakte löschen“. Doch wie sieht es bei einem blinden oder sehbehinderten Nutzer aus? Wie kann ein blinder oder sehbehinderter Nutzer Hinweise darauf erhalten, was passiert ist, als auf „Speichern“ oder „Kontakte löschen“ getippt wurde? Wenn ein VoiceOver-Nutzer auf die Schaltfläche „Speichern“ tippt, verkündet VoiceOver standardmäßig nur „Speichern“. Es gibt keinen Hinweis darauf, was gespeichert wurde oder ob der Speichervorgang erfolgreich war oder nicht. Ähnlich verhält es sich, wenn ein VoiceOver-Nutzer auf die Schaltfläche „Kontakte löschen“ tippt: VoiceOver sagt lediglich „Kontakte löschen“ an. Hier kommen dynamische Benachrichtigungen ins Spiel!

Nachdem die Schaltfläche „Kontakte löschen“ gedrückt wurde

Wenn „Kontakte löschen“ gedrückt wird, wird die Funktion (NSString*)clearList wird aufgerufen. clearList löscht alle Kontakte aus der Kontaktliste und ruft an UIAccessibilityPostNotification um den VoiceOver-Nutzer darüber zu informieren, ob die Liste erfolgreich gelöscht wurde. Der Code der Funktion ist unten aufgeführt.

[code language=”objc”]
– (NSString*)clearList {
NSString* announcement;

//Creates announcement for if the list was cleared when clearContacts button was pressed.
if([_contactList count] == 0) {
announcement = NSLocalizedString(@"NO_CONTACTS", nil);
} else {
announcement = NSLocalizedString(@"CONTACTS_DELETED", nil);
}

[_contactList removeAllObjects];
[self._tableView reloadData];
[DQUtilities createDynamicNotification:announcement]; // Fordert VoiceOver auf, die Änderung in der Liste anzukündigen.

Rückgabemeldung;
}
[/code]

Beachten Sie, dass die Funktion zunächst prüft, ob die Kontaktliste leer ist oder nicht. Anschließend erstellt sie je nach Kontext eine Meldung mit der lokalisierten Zeichenfolge „NO_CONTACTS“ oder „CONTACTS_DELETED“. (Eine lokalisierte Zeichenfolge ist eine Zeichenfolge, die in der Datei „Localizable.strings“ hinterlegt ist, sodass im Falle einer Übersetzung Ihrer App alle programmgesteuert definierten Zeichenfolgen leicht in einer einzigen Datei gefunden werden können.) „NO_CONTACTS“ ist in der Datei „Localizable.strings“ als „Kontaktliste leer – keine Kontakte gelöscht“ definiert, und „CONTACTS_DELETED“ ist als „Kontakte wurden gelöscht“ definiert. Also, NSString announcement wird entweder „Kontaktliste leer – keine Kontakte gelöscht“ oder „Kontakte wurden gelöscht“ zugewiesen. Dies NSString wird dann an die Funktion übergeben createDynamicNotification. Nachfolgend finden Sie den Code für createDynamicNotification.

[code language=”objc”]
+ (void)createDynamicNotification:(NSString*)announcement {
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, NSEC_PER_SEC), dispatch_get_main_queue(), ^{
UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, announcement);
});
}
[/code]

createDynamicNotification Anrufe UIAccessibilityPostNotification, dessen erster Parameter wie folgt definiert ist: UIAccessibilityAnnouncementNotification. createDynamicNotification Anrufe dispatch_time, eine Zeitverzögerungsfunktion, um sicherzustellen, dass die Benachrichtigung von VoiceOver ausgegeben wird. Auf diese Weise wird unsere Benachrichtigung „Kontakte wurden gelöscht“, wenn „Kontakte löschen“ gedrückt wird, nicht durch die Ansage „Kontakte löschen“ von VoiceOver unterbrochen. Wenn also auf „Kontakte löschen“ getippt wird und die Kontaktliste leer ist, wird der VoiceOver-Nutzer darüber informiert, dass keine Kontakte gelöscht wurden, da die Liste leer ist. Ist die Kontaktliste nicht leer, wird der VoiceOver-Nutzer darüber informiert, dass die Kontakte erfolgreich gelöscht wurden.

Nachdem auf „Speichern“ geklickt wurde

Die Schaltfläche „Speichern“ ist auf ähnliche Weise implementiert. Wenn „Speichern“ angeklickt wird, führt die Funktion saveItem wird aufgerufen, das Folgendes enthält: UIAccessibilityPostNotification. saveItem prüft, ob das Textfeld leer ist, und falls ja, weist es VoiceOver an, die Meldung „Textfeld leer – kein Name zu den Kontakten hinzugefügt“ auszugeben. Ist das Textfeld nicht leer, gibt VoiceOver die Meldung „Artikel „wurde zu den Kontakten hinzugefügt“, wobei Artikel ist der Text, der in das Textfeld eingegeben wurde. saveItem Anschließend wird das Textfeld geleert, die Tastatur ausgeblendet und der Kontakt zur Liste hinzugefügt.

Wenn Sie den vollständigen Code zu diesem Beispiel einsehen möchten, finden Sie ihn auf GitHub.

Tipps

• Verwenden Sie das UIAccessibilityLayoutChangedNotification NSStrings nicht zu verwenden, da es möglicherweise nicht funktioniert. Es ist bekannt, dass es fehleranfällig ist.
• Stellen Sie sicher, dass Sie genügend Benachrichtigungen einrichten, damit Ihre Nutzer erkennen, wenn sich etwas ändert, aber nicht so viele, dass VoiceOver mit Benachrichtigungen überlastet wird und Ihre App unbrauchbar wird.
• Bei der Verwendung von UIAccessibilityAnnouncementNotification, oder bei jeder Mitteilung, in der NSStrings angekündigt werden, beschränken Sie Ihre Mitteilung auf höchstens einen Satz. Halten Sie sie kurz und informativ!

Wir hoffen, dass euch diese Anleitung weitergeholfen hat! Schaut euch unsere App „Deque University für iOS“ an, um weitere Anleitungen zum Thema Barrierefreiheit zu erhalten!