Re: motion or scaling animations

Thanks Michael, David,

To help discussion on this I think we need a slight refresher on the purpose (I know I did!).

I did the understanding doc recently, not in master yet but here:
http://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html


To summarise from that what the SC needs to achieve, it needs to:

  *   Be scoped to content-based animations triggered by user-interaction (2.2.2 covers content-triggered automatically without user-interaction).

  *   Prevent the animation in the first place, in order to avoid triggering.

  *   Allow for user-agent preference (which is the more elegant solution, in progress), or an on-site preference.

For some concrete examples:


  *   We don’t want to catch a menu drop-down that appears (without ‘moving’ or ‘scaling’), but we do if it swooshes in from above, or grows from small to full size. Appearing is required (and not a trigger), moving/scaling is not.

  *   We do want to catch parallax (or other) animation added to scrolling.
One extreme example: http://taotajima.jp/works/bravia-2017/ (massive TRIGGER warning!).
Or http://apple.com/macpro

Or https://articulate.com/360/rise (scroll down and some of the images move in addition to scrolling).

  *   We do want to catch the ‘slow scroll’ technique like selecting the links at the top of this page: http://www.masterlock.com/bluetooth

(The technique would be to simply jump to each anchor, like browser functionality for going to anchors.)

This article is excellent as background, with examples: https://webkit.org/blog/7551/responsive-design-for-motion/


In every case these are animations the author has added, so there are three methods/techniques:

  *   Don’t add them (bit harsh, but it is AAA).
  *   Put the triggers behind the reduce-motion preference (available in Safari desktop and iOS, others hopefully to follow).
  *   Include a mechanism on the site that has the same effect as the reduce-motion preference.

Therefore my preferred formulation is:
“Motion or size animations triggered by a user action can be disabled without preventing the action, unless the animation is essential to the functionality or the information being conveyed.”

NB: I liked David’s starting point of “Content can be operated without Motion or scaling animations…”
However, I think that makes the second half more difficult when defining what is allowed vs disabled. For anyone not adding “Motion or scaling animations”, you don’t need to worry about this.

Compared to other versions:

  *   “Preventing” rather than “affecting”, as stopping the motion/scaling animation does affect it, but doesn’t prevent it.

  *   No mention of user-agent or ‘provided by content’, because I would argue that anything done by the user-agent is essential to the action. If it isn’t user-agent, it is content.

  *   “Scaling” has alternative meanings (mostly to do with fish), so I thought size made more sense here. Saves a definition.

If people don’t agree that user-agent animation is essential, then I’d suggest:
“Motion or scaling animations provided by the content and triggered by a user action can be disabled without preventing the action, unless the animation is essential to the functionality or the information being conveyed.”

Bit wordier, but narrower.

For a definition of motion, I’m not convinced we need anything beyond the dictionary definition?
http://www.dictionary.com/browse/motion


Also, there is a good note in the webkit article I linked above, which we might want to include in some form like this:
“Note: This criterion does not apply to user-controlled direct manipulation effects such as pinch-to-zoom or browser scrolling that are provided by the user-agent. Those interactions are predictable and the user can choose to manipulate the interface in a style or speed that works for their needs.”

Kind regards,

-Alastair