Understanding "Pause, Stop, Hide": adding explanation of "automatic".

[dan-tripp-siteimprove]

Closes #2863

[dan-tripp-siteimprove]

Regarding "PR has contribution issues. The following users' affiliation could not be determined: @dan-tripp-siteimprove.": I linked my w3c account with my github account, but I don't know if it worked. Let me know if there's anything else that I should do.

[JAWS-test]

"starts automatically" as it relates to user interactions: for the animated information to start on a change of focus is considered automatic. For the animated information to start on pointer hover, scrolling the page, or on changing the setting of a user interface component is not considered automatic.

I think this is problematic because this is an arbitrary interpretation of "automatically starting" that is not derived from the SC and for which I think there is no consensus.

Also, I don't see the difference between an automatically starting action is that happens on hover or focus change. I think we need automatic changes on user interaction either a new SC or rather an addition in the definition of change of context for SC 3.2.1.

[patrickhlauke]

agree this feels slightly arbitrary as a measure (on change of focus: automatic; on scrolling/hovering/doing other things: not automatic). seems much clearer to say take the general view that: automatic = anything that didn't involve the user explicitly choosing to activate something (like a link or button), though of course that's a bit handwavy too.

will there be cases where there's still overlap between 2.2.2 Pause, Stop, Hide and 2.3.3 Animation from Interactions? probably.

but i'd say that:

• 2.2.2 (at A) allows for animations/videos/etc (though limited to "information", so arguably not just "eye-candy" type animations) to happen first, as long as there's a way for the user to then pause/stop/hide things.
• 2.3.3 (at AAA) is a stricter requirement (but scoped only to motion animations ... but these can be "eye-candy" only ones, not "information") that asks for the ability of users to suppress/turn off these animations before they even happen

In short, I personally don't think this PR is quite correct. I'd rather see additions to the understanding for 2.2.2 and 2.3.3 along the lines above (assuming my take/interpretation is correct)

[patrickhlauke]

Don't think the differentiation this PR tries to make is valid

[mbgower]

Also, review On Focus to ensure we don't step on toes of that requirement.

[mgifford]

We have to figure out what is intended here, but I think that this language is clearer, should we want to proceed with this suggestion.

<p>When animation starts automatically with a change of focus, it's considered automatic. However, animation starting from pointer hover, scrolling, or changing a UI component is not automatic.</p>

<p>"Pause, Stop, Hide" applies to animations initiated by the web page. For animations triggered by user interactions, refer to <a href="animation-from-interactions.html">2.3.3 Animation from Interactions</a>.</p>

[mbgower]

@dbjorge also mentioned that Animation from Interaction needs to be taken into account.

[patrickhlauke]

Bring in the idea of "user intent" - it might happen "automatically" after a user interaction, but if the interaction is arguably not about starting/stopping stuff (like pressing a play/pause button), and it would be a surprise for users, then it's "automatic" (incidental) and therefore falls under the considerations of the SC

[dan-tripp-siteimprove]

Good points, all. Still, I (personally) can't see how to move forward with this. Maybe someone else can. If not, then I imagine this PR should be closed.

[nattarnoff]

When I first brought forward the idea of animation from interactions, the intent was specifically for anything the user initiated that had animation attached to the action would have a mode where the animation doesn't play. Specific things mentioned were:

• Scrolling
• Click
• Hover
  I think @patrickhlauke is right that an animation that happens post action where the action is not starting the animation falls outside of 2.3.3. An example might be around scrolling. The natural way to consume the page is scrolling, if I scroll half way down the page and an animation starts once it has entered the viewport, I don't consider that "animation from interaction" but rather what Patrick mentions. Now on a different page, there is no content until I start scrolling and the content sweeps in as I scroll, this is where 2.3.3 applies. The scrolling is directly tied to the motion happening, but needs a non-animated fallback. A good example of this would be the scrolling and assembly Apple had on the "trash can" Mac page.

I say this because if we can clearly define "animation from interaction" anything else left is "automatic."

But to get more specific than that - any animation or motion the author intends to have play without the user needing to do anything, I consider automatic.

I don't know that this necessarily clears things up, but if intent is worth anything maybe it helps narrow the issue slightly.

[patrickhlauke]

i think it's also worth acknowledging that there can be overlap between this SC and motion from interaction. the latter only covers motion, while this SC also covers other visual effects (color changes/fading/appearing things, audio playback/sounds). and to me the crux is user expectation - a user activates a PLAY button and some video starts? cool. they press something else, or hover, or scroll, and song and dance starts happening? fail (potentially, if no way to pause/stop/hide)

[patrickhlauke]

I've made a counter-proposal to address this problem here #4012

[patrickhlauke]

I think this is now superseded by #4012 which we've been actively tweaking/discussing in recent meetings.