{"id":7549,"date":"2017-04-02T19:54:40","date_gmt":"2017-04-02T23:54:40","guid":{"rendered":"http:\/\/www.useragentman.com\/blog\/?p=7549"},"modified":"2019-04-10T15:42:09","modified_gmt":"2019-04-10T19:42:09","slug":"using-peat-to-create-seizureless-web-animations","status":"publish","type":"post","link":"http:\/\/www.useragentman.com\/blog\/2017\/04\/02\/using-peat-to-create-seizureless-web-animations\/","title":{"rendered":"Using PEAT To Create Seizureless Web Animations"},"content":{"rendered":"\r\n
\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n<\/picture>\r\n<\/div>\r\n

Recently, an accessibility-savvy client asked me if one of the animations they were planning to place on their website could cause seizures with people who have Photosensitive Epilepsy<\/a>. There are several examples of this happening in the real world, such as this Pok\u00e9mon episode that caused seizures in several Japanese children in 1997<\/a>, this promotional video for the 2012 Olympic Games in London<\/a> and even a case of someone trying to induce a seizure in someone on purpose with an animated GIF<\/a>. The avoid this from happening in accessible web applications, the W3C’s Web Content Accessibility Guidelines<\/a> require that a web page cannot “contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds” (this is known as the Three Flashes or Below Threshold<\/a> requirement)<\/p>\n

Testing this requirement may seem a little daunting at first, but luckily there is a free tool called PEAT<\/a> that web developers can use to test if their animations and videos can cause an epileptic attack in those with Photosensitive Epilepsy. The help files<\/a> for it are really good at explaining how the seizure risk is determined using the Harding Test<\/a> (and even what a general flash and a red flash is). However, when I installed it on my computer, I found that there were limitations:<\/p>\n

    \n
  1. It is Windows-only (and my work computer is a Mac).<\/li>\n
  2. While it states that you can capture the animation running on a web browser, I have found this difficult to get working, especially if you are running PEAT in a virtual machine such as VirtualBox (did I mention my work computer was a Mac?)<\/li>\n
  3. A work around for the previous point is that you can give PEAT a video capture to analyze. However, the video must be an uncompressed AVI (and most Mac tools deal primarily with MP4 or Quicktime Videos)<\/li>\n<\/ol>\n

    In order to work around these issues, we need to produce a video capture, convert it to an uncompressed AVI, and then let PEAT analyze that. <\/p>\n

    Step 1: Producing a Video Capture of Your Web Browser<\/h2>\n

    On a Mac, use Quicktime to capture the video of your animation<\/a>. On Windows 10, you can use this built-in feature in Windows to capture video<\/a>, but since not all computers running Windows support it<\/a>, you may find CamStudio<\/a> a good alternative (Note: I have not used either Windows solution to capture video, so your mileage may vary).<\/p>\n

    Step 2: Convert the Video to Uncompressed AVI format<\/h2>\n

    PEAT is guaranteed to analyze 25 frame-per-second uncompressed AVIs<\/a>. I have used FFmpeg<\/a> to convert other types of video content to this format. Once you download the program<\/a> (or install it with your favourite package manager like macports, brew, or cygwin), you can use the following command line recipe to do this:<\/p>\n

    \n
    \r\nffmpeg -i input.mp4<\/em> -an -vcodec rawvideo -y -r 25 output.avi<\/em>\r\n<\/pre>\n<\/blockquote>\n
    For those who are interested: the -an<\/code> removes the audio (since PEAT doesn’t need it to analyze the video), the -vcodec rawvideo<\/code> converts the output to an uncompressed format, the -y<\/code> will overwrite the video without asking, and the -r 25<\/code> will ensure the output video has a framerate of 25 frames-per-second.  Note that even though I use an MPEG-4 as the input video in the command above, FFmpeg can read and write a variety of other video formats<\/a>.<\/p>\n
    Sometimes PEAT will fail to read the uncompressed video, or only analyze part of the video, because it’s too big.  In that case, you should resize the video using this ffmpeg recipe:<\/p>\n
    \n
    \r\nffmpeg -i input.mp4<\/em> -vf scale=640:-1<\/span> -an -vcodec rawvideo -y -r 25 output.avi<\/em>\r\n<\/pre>\n<\/blockquote>\n
    This will rescale the video to 640 pixels across without changing the aspect ratio.  This rescale is acceptable for seizure testing purposes.<\/p>\n
    Step 3: Get PEAT to analyze the video<\/h2>\n
    You can now use PEAT to analyze the input file.  If you are using a Mac or Linux, use VirtualBox or another type of Virtual Machine software to run it on a copy of Windows (this can be done by  downloading one of the modern.IE Windows 10 virtual machine images<\/a> from Microsoft’s developer website).  You can open the file using File → Open<\/strong> and then analyze the video using Analysis → Analyze Video<\/strong>.  To show how it works, let’s give PEAT a video capture of a game I have been developing in my spare time:<\/p>\n
    \n
    \n
    \n
    <\/div>\n<\/div>\n
     Progress on my #html5 #JavaScript port of #KCMunchkin. Playable!<\/a><\/p>\n
    A post shared by Zoltan "Du Lac" Hawryluk (@zoltandulac) on 
    When I put this video through PEAT, it starts producing a graph like this:<\/p>\n
    \"PEAT<\/a><\/p>\n
    As you can see from the graph, the animations used in the video are safe — the only times the graph starts spiking are when the monsters start flashing, but this flashing is well within acceptable levels (the tool shows some light luminance flash).<\/p>\n
    To show how the tool behaves when it comes across a bad animation, I fed it a the seizure inducing scene from Pok\u00e9mon that I mentioned earlier. I do not link to the video, since I don’t want people getting seizures as a result of going to my blog (if you want to see it, search for it in YouTube), but here is what PEAT displays when it came across the seizure-inducing part of the show:<\/p>\n
    \"screenshot<\/a><\/p>\n
    Note that both luminance and red flash metrics are going off the charts.  Flashing saturated reds are especially bad for those who susceptible to seizures.<\/p>\n
    Further Reading<\/h2>\n
      \n
    • W3C page on WCAG requirement 2.3.1, Three Flashes or Below Threshold: (Understanding SC 2.3.1)<\/a><\/li>\n
    • PEAT download page<\/a><\/li>\n
    • Pokemon snopes article<\/a><\/li>\n
    • Twitter user arrested for sending seizure-inducing GIF<\/a> on avclub.com.<\/li>\n
    • Wikipedia article on the Harding Test<\/a><\/li>\n<\/ul>\n
      Acknowledgments<\/h2>\n
      Header photo credit: Gerd Altmann<\/a>.<\/p>\n