Re: Testability of Animation from interactions Issue 18

Alastair Campbell schrieb am 16.01.2017 12:29:

> Hi Detlev,
> 
> As it stands, no, because there is no movement involved that isn’t part of
> ‘normal’ scrolling.
> 
> I’m not sure if we /should/ be trying to cover colour changes (without
> movement), that hasn’t come up in the examples of triggering animation, so
> probably not.

I guess it would depend on how disruptive the colour change is - imagine scrolling would start rapid changes that would even qualify as a flicker. We would want to catch this (although this is unlikely to be used unless the designer is bent on irritating users).

> 
> Cheers,
> 
> -Alastair
> 
> 
> On 16/01/2017, 11:27, "Detlev Fischer" <detlev.fischer@testkreis.de> wrote:
> 
>    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):
>    https://www.muenchner-kammerspiele.de/en
>    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:
>    > 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.”
>    
>    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!
>    > 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 11:42:24 UTC