Comments: Issue 18 Animation from interactions

Use percent of visual field on the screen

The part that I wouldn't know (at first) how to test is "how would I measure 1/3 of a web page view". And while this may be a bit of a tough questions to answer...I bet it is answerable (and maybe...some smart person could up with a tool that helps us consistently and reliable measure this!)

Reminds me of the small enough part of flash thresholds. Honestly, every time I read "occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance" my eyes glaze over and I'm grateful I have not had to measure that yet!

general flash and red flash thresholds

a flash <https://www.w3.org/TR/2008/REC-WCAG20-20081211/#flash-def> or rapidly changing image sequence is below the threshold (i.e., content *passes*) if any of the following are true:

- there are no more than three *general flashes* and / or no more than three *red flashes* within any one-second period; or - the combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance

Rather than 1/3 of the web page...what if you used language like (33% of any 10 degree visual field on the screen)....or whatever the percent would be to address the accessibility barrier that this proposed SC is trying to prevent.

Use >500 CSS PX

- For the field, perhaps saying something like it has >500 CSS PX again that is fairly arbitrary... but at least measurable.

Use CSS pixels (aka David)

Some quick thoughts on this. (Noticed this in passing)

1) I agree that the animation size needs to be clearly defined.

2) I agree with Patrick that 10 degrees of visual field won’t work you can’t calculate that unless you know a) how far the person is from the screen b) the size of the screen and c) the pixel resolution of the screen d) the scaling of the screen. None of these are known to the author and change from user to user (Most people couldn’t calculate it if they did know those things)

3) You can’t use 1/3 of web page because a web page could be 500 ‘pages’ long so nothing would be 1/3 of it. and you can’t use 1/3 of screen for the same reason as #2 above.

4) I THINK — Doing it in CSS pixels (aka David) is the best bet but remember that a large blinking “O" only changes a relatively small number of pixels -- so you might look at pixel area rather than pixels.

Apologies, I see that you agreed with "1/3 of the web page" as being baffling in my original email, while I also included (and more so) "33% of any 10 degree visual field on the screen" as a source of bafflement.

Taken a step back then, does "visual field on the screen" as in the current WCAG 2.0 definition actually mean, in essence, the overall size of the screen? If so, the suggestion below still stands (referring to "viewport size" rather than "web page")

Use Percentage of overall screen/viewport size. i.e. "more than 1/4 of the viewport"

Use 1/3 of the screen

Not sure 500px works

Regarding 500px, that's far easier than the general flash and red flash thresholds text, but I'm not sure it is there yet.

500px on a page, assuming you mean total pixels, is about 22px x 23px, around the size of an "M" in a heading. That might be significant on a tiny screen, but on most things we can allow for much more!

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.

Parallax scrolling usually invovles the full viewport. Dissallow it or provide mechanism

Just reading through this thread - if the main user issue in user-initiated animation is really parallax scrolling, can we not focus on that - assuming that it will mostly involve the entire viewpoint - and demand that it’s either avoided or, when used, there are UA, or a11y-supported common browser or site settings available that will disable parallax scrolling?

Regarding other smaller animations, it will be very difficult to define / quantify the type of animation and in turn how distracting it may be - on a continuous scale from slow / subtle / hardly noticeable and not a problem at all, to really annoying

On 14/01/2017 16:11, Detlev Fischer wrote:
> Good point. That parallax scroll would be too specific for an SC is
> true - one could extend the requirement to any user-initiated
> animation that affects the entire viewport (or a large part of it)

So just the whole viewport, and not "1/3 of the viewport"?
https://github.com/w3c/wcag21/issues/18#issuecomment-272346989

> whether it is nauseous shifts, swirls, wobbles, colour changes or
> some other brainchild of the inventive front end designer. My attempt
> would be to set this class of animation apart from another class
> focussing on specific 'elements' (changing shape or position when
> focussed or moved, disappearing in an inverted Aladdin's lamp fashion
> in some location, etc). That might alleviate the need to talk about
> the size of the area affected,

Though you're talking about the entire viewport, so you ARE specifying a size.

> which in the absence of further
> information on the nature of the movement seems inconclusive.

But agree, would like to see some empirical evidence of different types of animations and how they can be disruptive/problematic.

I'm a little concerned that "1/3 of the webpage view" is a tough way to measure parallax, which I believe is one of THE biggest culprits here.

surely classic parallax scrolling affects the entire viewport, so crosses the "1/3 of the viewport" (using the more accurate definition here rather than "webpage view") with ease?

I think merely from a testing standpoint, the easiest would be to say "at least 1/2 of the viewport". That would be easy to establish visually im most cases Depending on the type of animation it might still need a reference viewport size (such as 1280 x 768px) at which the SC is found to fail if animation indeed affects only part of the viewport

...

Even if we get empirical evidence, types of animation can be so different that we will never be able to drwaw the line would qualify as problematic from a user perspective. Take two hypothetical cases:

(1) As the user moves the mouse, vivid pumping bubbles appear and disappear around it (I hope no one will get the idea to actually build this). The total surface area of animation at any time is well below 1/3 of the viewport, but the animation is highly disruptive and irritating.

(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.

Going for 'percentage of viewport affected' alone to make this SC "objectively, replicably testable" we would fail to take into account the actual disruptive quality of the animation.

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.

So homing in on parallax (maybe describing it in a more abstract fashion, e.g. "presence of miore than one layer moving at different speed or/and in different direction) would at least nail down *some issues* that we know are problematic. The alternative might be to say "Sorry, nice SC, but unfortunately not testable".

Either a third or a half of the viewport would be a good metric for me.

3 second lower threshold (prefers less)

I didn't include time as a factor in my survey. Pushing my personal feelings and experiences aside, I think animation settling by 3 seconds makes sense (I prefer less, but I'm an extreme case).

3 second lower threshold- if it stops in 3 seconds it would pass

the 3 second was actually a lower threshold proposal instead of 1 second. In other words if it stops in 3 seconds it would pass the SC. Or maybe 2 seconds... this would allow for transitions etc. which are entrenched on the web, forbidding fades etc and will likely cause push back...

2 seconds threshold

- I would say 2 seconds threshold, so any animation less than 2 seconds passes, allowing most CSS transitions, which are an important design paradigm.

longer than 3 seconds that can’t be stopped

I wouldn't ban it - but rather ban anything the has a duration longer than say three seconds that can’t be stopped. Such animations are very useful for directing attention for people with cognitive disabilities. Also important sometimes for warnings.

We are defining a *lower* limit

Regarding significant animation: please remember that it is aimed at things like parallax ("triggered by a user action"), so we are defining a *lower* limit so we can ignore quick animations, not an upper one like the current animation SC.

Nat explained that he uses a 'long blink' to cope with auto-scrolls and similar whole-page movement that he isn't controlling, so the 1 second came from there. His follow up [1] indicates a longer time might be ok, but we are lacking wider scale research.

Parallax (in most cases) lasts as long as you scroll it, there is no pre-set time for it, but you can't avoid it either.

@alastc I think as per @nattarnoff above mentioned Let's set the threshold to 3 seconds not 1 second. That will allow most CSS transitions and save a lot of testing time, which of course would focus on a stop watch an a 1 second boundary. Also incorporating Patrick's suggestions.

I wanted to express my concern with the threshold. Here's the issue: how can time be used as a measure to capture failure when the animation 'response' only lasts as long as the user action. In other words, if I don't ever scroll for 3 seconds straight, I would never trigger enough animation to fail the threshold. That is true not matter what the time threshold is set at, so I'm concerned that it is part of a 4-part AND statement to reach failure.

What would happen if the third parameter "the animation takes more than 1 second and affects more than 1/3 of the webpage view" became 2 different items, and you put an OR in:
3) the animation takes more than 1 second or is synchronized with a user action, and
4) the animation affects more than 1/3 of the webpage view, and

The wording is awkward and imperfect, but hopefully you get the idea I'm trying to cover and we can improve -- if the animation is continuous for as long as the user action takes place (i.e., parallax while scrolling) than it shouldn't matter what its duration is.

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?

Alastair Campbell schrieb am 16.01.2017 12:29:

> 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).

I don't know but if the definition is for "significant animation" perhaps we shouldn't use "animation" in the definition also, so maybe for the first draft something like.

Significant animation: Movement which continues for more than 2 seconds, and occupies more than 500 CSS pixels on the webpage.

Significant animation: animation which continues for more than 3 seconds, and affects more than 1/3 of the viewport.

Nat's user survey results

A high summary is:

• Parallax sucks.
• Color fades are not a problem at any size
• Shape changes (Say circle to square) at less than 1/4 of the screen are not an issue at all.
• Moving items on the X or Y axis is fine if smaller than 1/4 the screen AND moves less than 1x away. So an object of 50 x 50 pixels moving on either the X or Y 50 pixels or less doesn't seem to be a problem for anyone.
• Zooming or movement on the Z axis is nearly always an issue, but a minor one if less than 1/8 the screen at the largest point.

...Additionally, accessible animation doesn't help just people with vestibular disorders. Poorly used animation has a tremendous impact on people with autistic, ADHD, PTSD, migraine & headaches, mental illness, epilepsy, and low vision or blindness. In fact, in my survey, motion sickness, vertigo, and vestibular disorders only made up 14% of respondents. Because of how animation is usually coded, screen reader users are large group that ANY animation can prevent an accessible experience. The combination of trying to hit higher frame rates and using display:none makes most content unreadable.

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

Here are some examples, TRIGGER WARNING for people with vestibular disorders!
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.)

A general 2015 parallax scrolling usability study turned up a couple of people who experienced motion sickness. The Effects of Parallax Scrolling on User Experience in Web Design By Dede Frederick, James Mohler, Mihaela Vorvoreanu, Ronald Glotzbach states:

"...two of the participants in the study suffered from motion sickness...

Tips for Usability Practitioners...

PS may cause certain people to experience nausea; therefore, it is important to screen your participants for motion sickness and vestibular disorders before allowing them to participate in a test."

It will cause many web sites to have to create a gear icon, or another button in addition to a "Pause" button on a carousel. One big thing is how to create a button that doesn't eat expensive real estate, that is easily understood. Is there an icon that people with vestibular disabilities would have? Does the dev add a button on the $50 million "above the fold" part of the page <button>Stop all animation on this site</button>

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.