Trigger Warnings in igital Accessibility
Undesirable effects in web applications and videos are relatively common and sometimes unavoidable. To my knowledge, trigger warnings do not yet appear in digital accessibility. I would like to discuss here when they can make sense and how they can be implemented.
What can be triggers?
In practice, there are countless disorders that can be triggered by countless triggers. Epilepsy is certainly the most well-known disease. There are also, for example, autism or certain forms of migraines. Parallax effects, for example, are suspected of triggering migraines in certain cases, but to my knowledge this has not yet been empirically proven.
In epilepsy, flashes and flickering are the main triggers. There is the famous example of an animated film from the 90s that caused epileptic seizures in numerous children. What is also interesting is that many people can have seizures for whom epilepsy has not previously been diagnosed. Effects can therefore unintentionally trigger a person's first epileptic seizure.
When it comes to autism, things are a little more complicated. Trigger warnings are less useful in this case for two reasons:
- There are a wide variety of triggers because what acts as a trigger is very individual: It can be a certain color combination, certain effects in videos or even movements of control Elements. It is unpredictable.
- Those affected know best what triggers them and, if possible, have developed strategies or adjustments to reduce it as much as possible.
We can also leave out the group of attention disorders. Although disruptions have a negative impact on your attention, they do not mean that you have to stop using the application and can already be covered with the other options mentioned here.
Therefore, the recommendation is to follow the WCAG when it comes to identifying possible triggers.
The topic in the WCAG
There are two main criteria in WCAG 2.2 that address the topic. First there is 2.2.2 Pause, stop, Hide::
For moving, blinking, scrolling, or auto-updating information, all of the following are true:
Moving, blinking, scrolling
For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
Auto-updating
For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
Source: Understanding SC 2.2.2:
The above criterion refers to animations triggered by the application. There is also the AAA criterion 2.3.3 Animation from Interactions, which refers to effects that are triggered by the user through interaction, for example by clicking on a UI element. Here too there can be effects such as flashing or flickering. Such effects should be able to be switched off completely if they are not essential for the application. As I said, an AAA criterion, so not mandatory.
There is also SC 2.3.1: Three Flashes or Below Threshold:
There is also an AAA version of the latter criterion, 2.3.2 Three Flashes, which generally does not allow flashing or flickering.
Use trigger warnings
The first step, of course, is to either not start animations automatically, stop them automatically after five seconds at most, or provide a mechanism to pause or hide them.
There are cases where this doesn't work. For example, in some public transport apps there is a animated element that is necessary for ticket controlling. Or there are videos that contain flashing or flickering for some reason and you can't remove it.
In general, of course, we don't want to decide what can be triggering for someone. This means that a subtle warning is enough that the following page may contain triggers of the form X, Y or Z. In the above example of the traffic app it could say: The following screen contains an animation that is necessary for ticket controlling. The person being checked can show the app and then close the app as quickly as possible. In order for the warning to be noticed, it should be visually highlighted and not hidden in a bunch of other text. I also think such a warning is useful if the next element contains self-starting audio or video content, which is extremely annoying for screen reader users or people who are hard of hearing.
In general, the warning should be non-obtrusive but noticeable. For example, it can be integrated as normal text content immediately before the trigger. In this case, I consider obstructive messages such as dialogs that have to be clicked away to be more annoying for people who are not affected by the trigger.
Another option that should definitely be used are the settings for reducing animations in the operating system. If someone has set their operating system to omit dispensable animations, you should also do this for the website or app, as long as the animations or movements are dispensable. Or you should integrate it in a way that the user can decide for herself when she wants to start it.
A special topic is videos or similar content that contain WCAG-relevant triggers. Here, too, it should be clearly stated in the still image or in the intro of the video or animation that such content can be found in the video and which triggers are specifically involved. If the video is essential for using the application, a text alternative should be offered. Please do not use such warnings preventatively for every video, but only when such content actually exists. Just because someone is epileptic or autistic doesn't mean they don't want to watch videos.
Configuration within the application
In some cases it may make sense to offer configuration options within the apps. Mainstream operating systems already have such functions for their own areas: For example, you can turn off unnecessary animations for user input, for example to reduce triggers, but also for battery saving purposes.
This makes sense for avoidable triggers, i.e. both for animations that are not triggered by user input and animations of control elements.
If such options are offered, they should be as easy to find as possible in the settings.