Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Issue 18: Animation from interactions #96

Closed
wants to merge 4 commits into from
Closed

Issue 18: Animation from interactions #96

wants to merge 4 commits into from

Conversation

lauracarlson
Copy link
Contributor

@lauracarlson lauracarlson commented Jan 30, 2017

Adding SC text and definition

Latest text and info:

SC Shortname

Animation from interactions

Note: The original issue was Animation from interactions.

SC Text

For significant animations 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 animations while still performing the same action.

Suggestion for Priority Level (A/AA/AAA)

Level A.

It extends "Pause, stop hide" (Level A) to cover another scenario.

Related Glossary additions or changes

Essential (already defined)

Significant animation: animation which continues for more than 3 seconds, or is synchronized with a user action (e.g. parallax scrolling effects), and affects more than 1/3 of the viewport.

What Principle and Guideline the SC falls within.

Principle 2, Guideline 2.2.

It applies the same principle as "2.2.2 Pause, Stop, Hide", which is under "Guideline 2.2 Enough Time".

Description

"SC 2.2.2 Pause, Stop, Hide" applies when the web page initiates animation, "Animation from interactions" should apply when an interaction of the user initiates animation unexpectedly.

When users take an action not normally associated with animation but some animation is triggered, it can cause distraction or nausea. For example, if scrolling a page causes elements to move (other than the normal movement associated with scrolling) it can trigger vestibular disorders, causing nausea and headaches. A good overview of vestibular disorders on A List Apart from a web design point of view, and an official organisation.

If backgrounds move at a different rate to foregrounds (often termed "parallax scrolling") that can be a trigger, as are foreground animations of items moving in or out of view, rotating etc.

This interview goes through examples. For more information please consult Evidence and Examples on the Wiki.

A webpage needs to either not use these types of animation, or provide mechanism for the user to turn them off.

Benefits

The people who benefit from this SC include those who benefit from "Pause, Stop, Hide", as it adds another situation where animation can be triggered. People with vestibular disorders are added as beneficiaries as they cannot always anticipate when animation happens, and are negatively affected if there is no warning or way of turning off the animations.

Note: The impact can be quite severe, triggering nausea, migraine, and potentially bed rest to recover.

Testability

For each example of animation on a page/view check if:

  1. The animation is triggered by a user-action, and
  2. the animation includes movement that is not essential to the action, and
  3. the animation continues for more than 3 seconds, or is synchronized with a user action, and affects more than 1/3 of the viewport
  4. there is no way of using the webpage without triggering the animation.

If all are true then it fails.

Techniques

Related Information

Articles

Surveys

<h4>Animation from interactions</h4>
<p class="conformance-level">A</p>
<p class="change">Unchanged</p>
<p>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.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"For significant animation...that is not...stop or hide the animation" > "For significant animations...that are not...stop or hide the animations"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the term significant needed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe so, but the definition itself (below) needs to be bolstered. Idea is to weed out "irrelevant" / non-problematic animations (e.g. something that's very subtle, like a very gentle colour change or similar, which nominally would be "animation" but doesn't cause problems to users)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @patrickhlauke ,

Thank you very much for the text and your comment on the February 7 2017 survey.

I updated the text at the top of this page and 62354ed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @joshueoconnor ,

Thank you for your comment on the February 7 2017 survey, Josh. You indicated "This SC needs more discussion" and wrote:

Dont think you need the term significant. And I'm not sure how this is that different from WCAG 2.0 and pause/stop etc moving content??

As stated in my January 17 status report to the working group the SC is about extending 2.2.2 "Pause, stop hide" to cover an additional scenario: when a person unexpectedly initiates an animation such as in parallax scrolling. Parallax scrolling involves a background moving at a different speed than foreground content, creating a special effect as a person scrolls down a page. It can trigger nausea and migraines in people with vestibular disorders.

Did you view examples in the video? For more information please consult Evidence and Examples on the Wiki.

The "significant animation" definition as Alastair said is to:

avoid small animations such as spring-loaded (but small) drop down menus.

Nat gave some examples of small helpful animations in the original issue:

Helpful animations would be more like the movement of the green box to indicate selection in this Dribbble or this verification notification on Stripe. Small, discrete, reduction of jarring changes that actually improve cognitive load or hide system/network lag.

Does that help?

@@ -1433,6 +1441,10 @@
<p>translation of one language, generally a spoken language, into a <a>sign language</a></p>
<p>True sign languages are independent languages that are unrelated to the spoken language(s) of the same country or region.</p>
</dd>
<dt><dfn>Significant animation</dfn></dt>
<dd>
<p>animation which continues for more than 3 seconds, or is synchronized with a user action, and affects more than 1/3 of the viewport.</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps adding "(e.g. parallax scrolling effects)" after "synchronized with a user action"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as noted above, "significant" needs to be explained/emphasised here. what is "significant" may be subjective, but giving examples would help...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patrickhlauke I updated the text at the top of this page with (e.g. parallax scrolling effects) as well as the pull request: 62354ed :-) Thank you!

@lauracarlson
Copy link
Contributor Author

lauracarlson commented Feb 8, 2017

Hi @michael-n-cooper

Thank you for your comment on the February 7, 2017 survey. You indicated "Accept this SC into the Editor's Draft with the following changes" and wrote:

Editorially, it needs "significant animation" to be wrapped in <a>; Respec will then pick up the link to the definition.

"whilst" should be "while" for W3C's US English policy.

I have updated the text at the top of this page and the pull request markup.

Given that a significant animation takes up at least 1/3 of the viewport, I wonder what such animation would not be viewed as essential. When I first read this I was thinking about those annoying tippy dongle buttons and stuff, but those don't meet the threshold. So I'm not clear what this SC actually does. For that reason, in turn I wonder if needs to be Level A. However, given that it's probably easy for most authors to conform by not triggering the conditions, I can live with it in the spec.

Thank you. As to where the SC would apply would be when a person unexpectedly initiates an animation such as in parallax scrolling. Did you view examples in the video? For more information please consult Evidence and Examples on the Wiki.

Yes, not triggering the conditions would be best. Second best would be providing a way to turn it off.

Michael, can you suggest a better way to word the SC?

@lauracarlson
Copy link
Contributor Author

lauracarlson commented Feb 8, 2017

Hi @gclowney ,

Thank you for your comment on the February 7, 2017 survey, Greg. You wrote:

I also fear that limiting this to animations affecting at least 1/3 of the viewport would limit its benefit to users with non-vestibular disorders, for whom size is less of an issue. As Nat pointed out, even where these are not a problem for users with vestibular disorders, they can still be problematic for users with other types of disorders.

I believe the initial catalyst for this SC was people with vestibular disabilities. (Is that correct @alastc ?) But I am open to including more use cases if others agree.

Greg, can you suggest SC text that would cover more use cases and still meet our SC requirements?

Imagine a person trying to drag using a sip-and-puff menu system while animations are active the entire time, or an easily distracted person trying to enter the name of a book while each character they type causes different suggested book covers to scroll into view.

If animations are active the entire time are they not already covered by the current 2.2.2 "Pause, stop hide"?

Book covers that scroll into view based on user input are an interesting case. Can you provide an example in the wild where this happens?

Does the definition of "synchronized with a user action" include starting when the action starts, and/or automatically ending when the action ends, and/or only animating when the action is actually changing (e.g. when moving the mouse during a drag, but not during the portions of that drag that the mouse is stationary)?

I'm also still concerned about whether this covers enough cases. Would the "synchronized" clause allow the developer to have animations happening the entire time someone is dragging, even if they are not essential to the operation?

Examples: Dragging an object through several screens of content that not only auto-scrolls the viewport (necessary) but also starts a prominent, 3-second animation of every icon that scrolls into view (bad) or that the drag passes over (also bad). A carousel of choices scrolls continually while the mouse is over a button. Thumbnails for video clips animate through representative frames the entire time the user is trying to select one.

@patrickhlauke suggested in the original Animation from interactions 18 issue "persists for the duration of the user interaction"

As @mbgower said in the in a comment in the original Animation from interactions 18 issue, "If something is synchronized with user actions, i think there is a clear inference of persisting. It's not "triggered" by user actions, it's synchronized. Qualifiers can be put in the Understanding doc. "

The idea was to cover this in the understanding document. Whatever we decide on can probably be explained there.

But if you can suggest SC text that covers more use cases, please do.

Thank you!

@lauracarlson
Copy link
Contributor Author

lauracarlson commented Feb 8, 2017

Hi @KimberleeD ,

Thank you for your comment on the February 7, 2017 survey and general support. Much appreciated. You wrote:

Accept this SC into the Editor's Draft with the following changes

Generally, I support this. I wonder about the "1/3 of the viewport" language though.

  1. Could this pass on one device (desktop) and fail on another (iPad) because of different sizes?

  2. What if the user had their screen enlarged? Is it at 100% only? How does that impact this SC?

I think the answers are yes and yes. @alastc please correct me if this is incorrect.

An example Alastair gave in the Testability of Animation from interactions Issue 18 Thread:

When reviewing the examples with Nat, whole-screen motion is the biggest issue, tiny animations are not an issue, so we came to about 1/3 of the screen being the point where it can trigger an issue for him.

Working up from the smallest practical screens, say 320x480px (153,600px) 1/3 of that would be ~50,000px, or 224px square.

@lauracarlson
Copy link
Contributor Author

lauracarlson commented Feb 8, 2017

Hi Adam Lund (sorry I don't know your Github username),

Thank you for your comment on the February 7, 2017 survey you indicated, "This SC needs more discussion" and wrote:

The SC will be very difficult to test and leaves a lot of ambiguity to the tester to get stuck. Testers need to understand the disorders for which the SC is intended to screen, and these disorders are not well understood.

I wonder if explanation in the understanding document may help?

How would you suggest the Testability section be simplified? It currently says:

Testability

For each example of animation on a page/view check if:

  1. The animation is triggered by a user-action, and
  2. the animation includes movement that is not essential to the action, and
  3. the animation continues for more than 3 seconds, or is synchronized with a user action, and affects more than 1/3 of the viewport
  4. there is no way of using the webpage without triggering the animation.

If all are true then it fails.

Thank you!

@lauracarlson
Copy link
Contributor Author

Hi @ bruce-usab ,

Thank you for your comment on the February 7, 2017 survey and support Bruce. You wrote:

Accept this SC into the Editor's Draft. I am okay with the SC, but a developer could argue just about anything applies to "an essential part of the action".

Yes I suppose they could. Is that a bad thing?

Essential is already defined in WCAG 2.0 as "if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform"

Thanks again,
Laura

lauracarlson added 3 commits February 9, 2017 03:20
<dfn data-lt="Significant animations">Significant animation</dfn>
Per @michael-n-cooper suggestions in the survey:

1. Wrapped "significant animation" in <a> so Respec will then pick up
the link to the definition.
2. Changed "whilst" to "while" for W3C's US English policy.
https://www.w3.org/2002/09/wbs/35422/SC_20170207/results#xq4

Per @patrickhlauke suggestions:

1. Changed "animation" to "animations”.
#96 (comment)
2. Added "(e.g. parallax scrolling effects)" after "synchronized with a
user action" to help clarify what is meant.
#96 (comment)
@alastc
Copy link
Contributor

alastc commented Feb 10, 2017

Just responding to @joshueoconnor and @michael-n-cooper, Josh wrote:

Dont think you need the term significant. And I'm not sure how this is that different from WCAG 2.0 and pause/stop etc moving content??

The trigger is different, so as per the description: "SC 2.2.2 Pause, Stop, Hide" applies when the web page initiates animation, "Animation from interactions" should apply when an interaction of the user initiates animation unexpectedly.

The 'essential' term is needed because moving the page as you scroll is necessary, but animating the background to move in the other direction as you do so is not. (Think paralax scrollling.)

"Significant" is needed to avoid small animations such as spring-loaded (but small) drop down menus.

@lauracarlson
Copy link
Contributor Author

Hi @Ryladog ,

Thank you for your comment on the February 7 2017 survey, Katie. You indicated "Accept this SC into the Editor's Draft" and wrote:

We may eventually change the size of the viewport, but I think it is important to share this concept and get feedback from those whom this might effect and those with experience and doing research in this area. Terms will need to be worked in the Glossary, but that shouldn't stop sharing the SC concept now.

I totally agree. Measures and definition may change based on new information.

@steverep
Copy link
Member

I really want to see this one go the distance, so forgive my nitpicking:

  • The phrase following "that is" is grammatically ambiguous as to whether it refers to the action or the animation. In fact, it is less likely to refer to the animations since the verb is not plural (i.e. "that are...")
  • Using "while" implies that the action is continuous or dynamic, i.e. it gets confusing if you are thinking more about an animation caused by a binary action like when tabbing to an element begins an unexpected animation. Personally, I think this entire phrase is implied and can be omitted, but use "when" instead if kept.

How about something like this (using brackets for options):

User interactions do not trigger significant animations which are not an essential part of the action, {unless | except where] a mechanism is available to pause, stop, or hide such animations [when performing the same action].

Also, consider defining a user action or interaction to specify not only the inclusion of binary and continuous triggers, but also to clarify the applicability to both the content and the user agent. Putting my extra sneaky hat on, the mechanism cannot be to zoom out until the scroll bar disappears.

@lauracarlson
Copy link
Contributor Author

Hi @steverep ,

You wrote:

I really want to see this one go the distance, so forgive my nitpicking:

The phrase following "that is" is grammatically ambiguous as to whether it refers to the action or the animation. In fact, it is less likely to refer to the animations since the verb is not plural (i.e. "that are...")

Using "while" implies that the action is continuous or dynamic, i.e. it gets confusing if you are thinking more about an animation caused by a binary action like when tabbing to an element begins an unexpected animation. Personally, I think this entire phrase is implied and can be omitted, but use "when" instead if kept.

How about something like this (using brackets for options):

User interactions do not trigger significant animations which are not an essential part of the action, {unless | except where] a mechanism is available to pause, stop, or hide such animations [when performing the same action].

Also, consider defining a user action or interaction to specify not only the inclusion of binary and continuous triggers, but also to clarify the applicability to both the content and the user agent. Putting my extra sneaky hat on, the mechanism cannot be to zoom out until the scroll bar disappears.

I like it, Steve. What do others think?

@lauracarlson
Copy link
Contributor Author

lauracarlson commented Feb 15, 2017

Hi again @steverep ,

Thank you for your comment on the February 7 2017 survey, Steve. You indicated "Accept this SC into the Editor's Draft" and wrote:

Discussion is fairly extensive and I think this is important to share in the first draft. I'm a bit confused by what constitutes a user action here though, but I'll post to GitHub for clarification.

The user action that the SC has been concerned with is when a person scrolls and unexpectedly initiates an animation such as in parallax scrolling. That was the impetus for the SC.

@steverep
Copy link
Member

Yep, understood. My confusion is elaborated in my previous comment, and I think fixed by my suggested rewording. I just want to make sure that such animations are prevented no matter what the user's action is. Thanks for being so thorough.

@lauracarlson
Copy link
Contributor Author

fyi:

@awkawk added this pull request to the 2.1 FPWD_review:
313cbc7

Thank you, Andrew!

@awkawk
Copy link
Member

awkawk commented Feb 27, 2017

Closed. Discussion takes place at Issue 18

@awkawk awkawk closed this Feb 27, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants