Graceful Enhancement: Add Sparkle to Your Site Without Hurting Your Users

HTML5 natively supports awesome interactive stuff, like the <video> element, that opens up possibilities to incorporate motion graphics and video into the design of your site. When done thoughtfully and deliberately, background videos can help improve user engagement and foster a stronger emotional connection with the content of your site. For some users, however, unexpected video content on websites can cause physical discomfort or pain. Background video is not always a good idea, but when it is, this approach needs to be thoughtful and implemented in a responsible way.

As browser support for <video> improves, it's important for designers, developers, and content authors to take steps to avoid inadvertently triggering a variety of unpleasant or dangerous conditions, including ADD/ADHD, motion sickness/simulation sickness, seizure disorders, and neurological headache disorders.

The consequences of exposure to physiologically triggering visual (or even auditory) material constitute a broad spectrum. I'm lucky enough to fall on the less scary end, but for people with more severe conditions the consequences can be dire. Some examples include:

• Seizures that cause discomfort and can debilitate someone for hours or days
• Loss of time at work
• Loss of ability to care for themselves or their children
• Triggering secondary illnesses like postictal psychosis

At the very least, triggering one of these conditions makes the site difficult or impossible to use.

One photosensitive victim of an epilepsy support site griefer attack described their flashing-graphic-induced seizure experience:

"I don't fall over and convulse, but it hurts. I was on the phone when it happened, and I couldn't move and couldn't speak."

While particularly sensitive users can protect themselves somewhat with browser extensions like Flashblock and NoScript, neither of these tools are completely effective at preventing the display of content that can trigger a sudden headache, seizure, wave of nausea, or unbearable distraction.

No one wants any user's primary reaction to their site to be closing the browser tab or crying, “Make it stop!" Luckily, the Web has guidelines of its own to prevent that, as well as those borrowed from television broadcasting and video game development.

Planning and Designing: Alternatives to Video

First of all, it's important to keep in mind that in many cases, auto-playing video may not be the best way to create visual interest or build a connection with your audience. In addition to being safer for people with any of the many conditions that may be sensitive to visual triggers, an alternative approach may be easier to implement and load faster than video.

There are a variety of ways to create the illusion of motion in your site, like a black and white image that slowly fades into color as the user scrolls or parallax scrolling that moves a photo or advances a flip book as an alternative. Putting the user in control of any movement drastically reduces the risk of surprise flashing or motion sickness.

The plethora of popular parallax scrolling effects available also eliminate the risk that somewhere down the line an uninformed or careless content author or editor will upload unsafe flashing or panning video to the site.

Prototyping and Building: Player Standards

While the videos themselves are up to the content authors, the elements and behaviors surrounding the videos are more often in the control of the designers and developers of sites. Whenever possible, designers and developers should work together to make sure there's a shared awareness of the different options for displaying video in an accessible manner.

Building in noticeable “stop" buttons, overlays or warnings before the beginning of a fast-moving video, slow fade-ins that give the user a moment to get oriented before being bombarded with unexpected visual stimulus — these are little features that can provide safeguards even if some future videographer decides to throw standards to the wind.

The WCAG provides pretty clear guidelines for dealing with moving, scrolling, or blinking items and how to pause, stop, or hide them. When implementing these, keep in mind that users with physical impairments who might not be able to use a mouse in a fluid motion, such as someone with Parkinson's disease, must also be able to use the controls on visual elements fast enough to protect themselves from visually triggering elements.

WCAG doesn't really say anything (that I could find) about motion sickness, but there is a bit of simulator sickness research that has to do with controls. This might be a use case for some of the fancy fade and transition stuff that HTML5 and CSS3 can do for us — if a user hits stop, or replay, or next, or if a playlist jumps to the next video, the evidence suggests that transition effects can make the difference between a nice experience and a gut-churning one for around a third of users.

Creating and Publishing: Content Standards

If you are choosing videos for a site, whether they autoplay or not, take the time to familiarize yourself with the UK OfCom Television Guidelines and WCAG 2 Standards for moving, blinking, and scrolling. Provide notes or warnings before links to videos that contain any rapidly flashing content or things that may aggravate motion sickness. Since not all types of seizure disorders are photosensitive in exactly the same way, and not all photosensitive conditions are seizure disorders, warnings for flashing content should simply describe the content rather than trying to identify a condition by name.

Additional best practices for accessible HTML background videos include:

• Choosing slow moving video clips with large blocks of color
• Avoiding fast-moving video or panning scenes that could cause motion sickness
• Adding blur to make sure that text that overlays video is legible
• Making sure that text is readable when any color appears underneath

Going Beyond the Standards

The twin ideas of graceful degradation and progressive enhancement have been the watchwords of inclusive design and development since the infancy of the Web itself and for the most part they've served us well.

However, sensitivities to certain kinds of video and motion graphics don't fit the progressive enhancement model particularly well, and this has become ever more relevant as the Web has become increasingly immersive and dazzling in the range of multimedia experiences it provides to its users.

You may have heard of the Dennō Senshi Porygon episode of Pokémon, best known for causing almost seven hundred children (and a few adults who happened to be watching) to be hospitalized for seizures triggered by a scene in which red and blue flashed rapidly on the screen. That scene complied with broadcast guidelines at the time, because it was not known for sure until that incident that color plays an important role in triggering photosensitive conditions. The majority of the victims of seizures triggered by that pattern had no history of seizures prior to that, and of those, the majority didn't have another seizure recorded after the event either.

We still know relatively little about the human brain and how visual patterns trigger neurological events, which is why the standards are useful as a rough guide but erring on the side of caution is recommended. Keep in mind that even content that complies with the available standards may still be enough to trigger painful conditions for some people.

Let's Make Something Safe Together

Making your sites safe and usable to as large a group as possible is a responsibility shared by designers, developer, content strategists, authors, and project stakeholders. Palantir works with its clients and uses accessibility checklists to help make sure that the sites we design and build can be easily and safely used by as many people as possible.

Like the Web itself, our methods and standards are constantly evolving and improving. Accessibility, adaptability, and usability of Web applications and their content are expanding concepts. They are no longer (if they ever were) fully served by simply adhering to the classic watchwords of “progressive enhancement" and “graceful degradation". We who build the Web must also ensure graceful enhancement. Question all of your assumptions about users, and endeavor to put the power into their hands.