Unerwünschte Effekte in Web-Applikationen und Videos sind relativ häufig und manchmal unvermeidbar. Trigger-Warnungen kommen nach meinem Wissen in der digitalen Barrierefreiheit bisher nicht vor. Ich möchte hier diskutieren, wann sie sinnvoll sein können und wie sie umsetzbar sind.
Was können Trigger sein?
In der Praxis gibt es zahllose Anfalls-Erkrankungen bzw. Störungen, die durch zahllose Trigger ausgelöst werden können. Epilepsie ist sicher die bekannteste Erkrankung. Daneben gibt es zum Beispiel Autismus oder bestimmte Formen von Migräne. Parallax-Effekte stehen zum Beispiel im Verdacht, dass sie in bestimmten Fällen Migräne auslösen können, was aber meines Wissens bislang nicht empirisch belegt ist.
Bei Epilepsie gelten vor allem Blitzen und Flackern als Trigger. Es gibt das berühmte Beispiel eines japanischen Animations-Films aus den 90er Jahren, der bei zahlreichen Kindern epileptische Anfälle ausgelöst hat. Interessant ist daran auch, dass viele Personen Anfälle bekommen können, bei denen bisher keine Epilepsie erkannt wurde. Effekte können also unbeabsichtigt den ersten epeleptischen Anfall bei einer Person auslösen.
Beim Thema Autismus ist es ein wenig komplizierter. Trigger-Warnungen sind in diesem Fall weniger sinnvoll aus zwei Gründen:
- Es gibt die verschiedensten Trigger, weil sehr individuell ist, was als Trigger wirkt: Es kann eine bestimmte Farb-Kombination, bestimmte Effekte in Videos oder auch Bewegungen von Bedien-Elementen sein, das ist nicht vorhersagbar.
- Die Betroffenen wissen selbst am besten, was sie triggert und haben wenn möglich Strategien oder Anpassungen entwickelt, um sie möglichst zu reduzieren.
Ebenfalls auslassen können wir die Gruppe der Aufmerksamkeits-Störungen. Zwar wirken sich für sie Störungen negativ auf die Aufmerksamkeit aus, sie führen aber nicht dazu, dass sie die Anwendung beenden müssen und können mit den anderen hier genannten Optionen bereits abgedeckt werden.
Daher lautet die Empfehlung, sich an die WCAG zu halten, was die Identifikation möglicher Trigger angeht.
Das Thema in der WCAG
Es gibt vor allem zwei Kriterien in der WCAG 2.2, die auf das Thema eingehen. Zunächst ist da 2.2.2 Pause, stop, hide, hier in der Übersetzung mit DeepL:
Für sich bewegende, blinkende, scrollende oder automatisch aktualisierende Informationen treffen alle der folgenden Punkte zu:
Für alle sich bewegenden, blinkenden oder scrollenden Informationen, die (1) automatisch starten, (2) länger als fünf Sekunden dauern und (3) parallel zu anderen Inhalten dargestellt werden, gibt es einen Mechanismus, mit dem der Nutzer sie anhalten, stoppen oder ausblenden kann, es sei denn, das Bewegen, Blinken oder Scrollen ist Teil einer Aktivität, für die es unerlässlich ist; und
Automatische Aktualisierung
Für jede sich automatisch aktualisierende Information, die (1) automatisch startet und (2) parallel zu anderen Inhalten dargestellt wird, gibt es einen Mechanismus, mit dem der Benutzer sie anhalten, stoppen oder ausblenden oder die Häufigkeit der Aktualisierung kontrollieren kann, es sei denn, die automatische Aktualisierung ist Teil einer Aktivität, für die sie unerlässlich ist.
Quelle: Understanding SC 2.2.2:
Das oben genannte Kriterium bezieht sich auf Animationen, die von der Anwendung ausgelöst werden. Daneben gibt es das AAA-Kriterium 2.3.3 Animation from Interactions, welches sich auf Effekte bezieht, die durch den Nutzer durch Interaktion ausgelöst werden, also etwa durch Klicken auf ein UI-Element. Auch hier kann es ja Effekte geben wie Blinken oder Blitzen. Solche Effekte sollen vollständig abschaltbar sein, wenn sie nicht für die Anwendung unerlässlich sind. Wie gesagt ein AAA-Kriterium, also nicht verpflichtend.
Daneben gibt es SC 2.3.1: Three Flashes or Below Threshold, wiederum mit DeepL übersetzt.
Webseiten enthalten keine Elemente, die innerhalb einer Sekunde mehr als dreimal aufblinken, oder das Aufblinken liegt unter den Schwellenwerten für allgemeines und rotes Blinken.
Quelle: Understanding SC 2.3.1 Three Flashes or Below Threshold
Vom letzteren Kriterium gibt es noch eine AAA-Version, 2.3.2 Three Flashes, die generell kein Blitzen und Flackern erlaubt.
Trigger-Warnungen einsetzen
Der erste Schritt ist natürlich, Animationen entweder nicht automatisch zu starten, sie automatisch anzuhalten oder einen Mechanismus zum Pausieren oder Ausblenden anzubieten.
Es gibt Fälle, wo das nicht funktioniert. Zum Beispiel gibt es in einigen Verkehrs-Apps ein bewegtes Element, dass für die Verkehrs-Kontrolle notwendig ist. Oder es gibt Videos, bei denen Blitzen oder Flackern aus irgendeinem Grund enthalten sind und man es nicht entfernen kann. Das heißt, eine dezente Warnung reicht, dass auf der folgenden Seite Trigger der Form X, Y oder Z enthalten sein können. Im obigen Beispiel der Verkehrs-App kann etwa stehen: Der folgende Screen enthält eine Animation, die für die Verkehrs-Kontrolle notwendig ist. Die kontrollierte Person kann die App vorzeigen und danach die App schnellst-möglich schließen. Damit die Warnung wahrgenommen ist, sollte sie optisch hervorgehoben bzw. nicht in einem Haufen anderen Text versteckt sein. Ich halte eine solche Warnung auch für sinnvoll, wenn im nächsten Element selbst-startende Audio- oder Video-Inhalte vorhanden sind, enorm nervig für Screenreader-Nutzende oder Schwerhörige.
Generell sollte die Warnung nicht-obstrusiv, aber wahrnehmbar sein. Sie kann zum Beispiel als normaler Text-Inhalt unmittelbar vor dem Trigger eingebunden werden. Obstrusive Meldungen wie wegzuklickende Dialoge halte ich in diesem Fall eher für störend für die Personen, die vom Trigger nicht betroffen sind.
Eine weitere Möglichkeit, die auf jeden Fall genutzt werden sollte sind die Einstellungen zur Reduktion von Animationen im Betriebssystem. Wenn jemand in seinem Betriebssystem eingestellt hat, dass sie verzichtbare Animationen weggelassen werden sollen, sollte man das auch für die Website oder App übernehmen, soweit die Animationen oder Bewegungen verzichtbar sind. Oder man sollte sie auf eine Weise einbinden, dass die Nutzerin selbst entscheiden kann, wann sie sie starten möchte.
Ein spezielles Thema sind Videos oder ähnliche Inhalte, die WCAG-relevante Trigger enthalten. Auch hier sollte im Standbild oder im Intro des Videos oder der Animation deutlich darauf hingewiesen werden, dass solche Inhalte im Video zu finden sind und um welche Trigger es sich konkret handelt. Ist das Video für die Nutzung der Applikation unerlässlich, sollte eine Text-Alternative angeboten werden. Bitte nutzen Sie solche Warnungen nicht präventiv für jedes Video, sondern nur, wenn solche Inhalte tatsächlich vorhanden sind. Nur weil jemand Epeleptikerin oder Autistin ist, heißt das nicht, dass sie sich keine Videos anschauen wollen.
Konfiguration innerhalb der Applikation
In manchen Fällen kann es sinnvoll sein, Konfigurations-Möglichkeiten innerhalb der Apps anzubieten. Mainstream-Betriebssysteme haben solche Funktionen für ihre eigenen Bereiche bereits: Man kann zum Beispiel unnötige Animationen für Nutzerinnen-Eingaben abstellen, etwa um Trigger zu verringern, aber auch für Zwecke der Batterie-Einsparung.
Das ist sinnvoll für vermeidbare Trigger, also sowohl für Animationen, die nicht von Eingaben der Nutzenden ausgelöst werden, als auch Animationen von Bedien-Elementen.
Bietet man solche Optionen an, sollten sie möglichst leicht in den Einstellungen auffindbar sein.