Re: Testability of Animation from interactions Issue 18

If you’d like to hear from the horse’s mouth (so to speak), I recommend this interview:
https://www.youtube.com/watch?v=QhnIZh0xwk0 

I consider this an extension to “Pause, Stop, Hide”, just with a different trigger that didn’t really exist when WCAG 2.0 was drafted. I don’t have numbers for how many people are affected, but again, if Apple got enough kick-back on iOS7 that they put in a user-setting to prevent animation, it is quite a lot!

The original idea was that it had to be:
- Animation that is triggered by a user action, AND
- The animation is not typically associated with the user-action, AND
- The animation fills a large part of the screen.

That was translated into:
“For significant animation triggered by a user action that is not an essential part of the action, there is a mechanism for the user to pause, stop or hide the animation whilst still performing the same action.”

Where “Significant animation” was defined as: “Animation which continues for more than 1 second, and affects more than 1/3 of the view of the webpage.”


> (2) A script changes the background of the page slowly and almost imperceptively from a light grey to a light greyish mint tone then to a pale tea tint and back to light grey. Contrast to text is always OK. There IS an animation, it affects the entire viewport, but some might not even notice it and few would find it disruptive. 
  
This wouldn’t be caught be the SC unless it is triggered by user action, that sounds like an automatic feature rather than triggered by the user.

Here are some examples, TRIGGER WARNING for people with vestibular dis-orders!
http://www.masterlock.com/bluetooth (scroll or use the top nav)
http://www.world-of-swiss.com/en (scroll)
https://recurly.com/ (Scroll about 2/3 of the way down and there is a Client stories carousel. Jumpy, hard stop animations are problematic. Easing helps a lot.)
http://www.apple.com/mac-pro/ (scroll, although the ‘dot’ menu on the right allows you to bypass the animation, so that should be a consideration.)

  
> Having said that, I fear that any attempt to nail down further criteria beyond 'percentage of viewport affected' will be hard to interpret in testing (especially as many aspects of moving content will be difficult to measure) and probably miss all sorts of real life instances because they will often not fall neatly under what we meant to capture.

Either a third or a half of the viewport would be a good metric for me. 

Please do watch the interview I linked to at the top, there is something import in this requirement, we just need to define it.
    
Kind regards,

-Alastair

Received on Monday, 16 January 2017 10:20:45 UTC