Re: Testability of Animation from interactions Issue 18

Hi Alastair,
thanks, I will check out the interview!

As to example 2, you are right of course, but the colour change could quite easily be triggered by scrolling as on this site (scroll right to the bottom):
Not as subtle here, but would you fail this according to the draft SC of issue 18?

> If you’d like to hear from the horse’s mouth (so to speak), I recommend
> this interview:
> 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.”

The way this is put ("whilst still performing the same action") makes me wonder how you would stop it in the middle of the action, i.e. when you notice it - an explicit control as in G186 would likely have to be at the top to be noticed (and we know that often it won't be noticed even then). Interesting to see what techniques we will come up with.
> 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!
> (scroll or use the top nav)
> (scroll)
> (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.)
> (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 11:27:58 UTC