[mediaqueries] prefers-reduced-motion prose leads readers to believe all animation should be stopped

[cookiecrook]

In MQ5 prefers-reduced-motion, the prose no longer accurately describes the intention of the feature.

Specifically, the prose makes it seem like users want no animation at all. Nothing in our research of vestibular motion sensitivity for the native platform features led us to this conclusion, so I'd like to propose the following changes in the spec.

The prefers-reduced-motion media feature is used to detect if the user has requested the system minimize the amount of animation or motion it uses.

"The prefers-reduced-motion media feature is used to detect if the user has requested that the system minimize the amount of non-essential motion it uses."

- animation or motion
+ non-essential motion

The main reason for the this change is that "animation" includes a variety of non-motion variants (opacity dissolves, for example) that when used appropriately are not problematic for those with vestibular or attention issues.

Indicates that user has notified the system that they prefer an interface that minimizes the amount of movement or animation, preferably to the point where all non-essential movement is removed.

"Indicates that user has notified the system that they prefer an interface that removes or replaces the types of motion-based animation that trigger discomfort for those with vestibular motion disorders."

- minimizes the amount of movement or animation, preferably to the point where all non-essential movement is removed.
+ removes or replaces the types of motion-based animation that trigger discomfort for those with vestibular motion sensitivity.

Note: I already made these changes to the PRM page on MDN.

The spec could also list or link to resources on the specific types of motion that are known to be problematic for vestibular motion sensitivity. Some of those were listed in the original PRM issue, and expanded upon in the WebKit post on prefers-reduced-motion.

If helpful, I can provide a PR on this issue.

[cookiecrook]

I think part of the reason for this confusion may be that when Microsoft added the feature a few years later, they called the native setting "Stop Animations" rather than "Reduce Motion."

[frivoal]

I support the first of the two changes you proposed without hesitation.

For the second one, I am less sure. Is this feature only of interest to people with with vestibular motion sensitivity? I thought this was the main use case,but that there were more, such as people who have trouble focusing on the main purpose of the page while some animation distracts their attention, and would also find that setting desirable. Your proposed phrasing focuses on vestibular motion sensitivity at the exclusion of anything else.

How about this instead keeping the original phrasing, and instead recycling your suggestion into a note:

Note: Authors are encouraged to pay particular attention to types of motion-based animation that trigger discomfort for those with vestibular motion sensitivity. See XXXX, YYYY, or ZZZZ for more information on this topic.

[cookiecrook]

@frivoal Yes. That seems like a good compromise.

[cookiecrook]

Actually I may have misunderstood. You said "I support the first of the two changes" but then it sounds like you disagree with the second? I thought your rephrasing was in place of the third change ("spec could also list or link to resources on the specific types of motion")

[cookiecrook]

Ah. I see. I misread "the first of the two" as "the first two."

[cookiecrook]

Here's the problematic phrase I'd like removed.

"…preferably to the point where all non-essential movement is removed."

There is a ton of research that indicates motion is useful in user interface, often designed in such a way that removing all movement degrades the usability of the interface. Both Microsoft's control name "Stop Animations" and this phrasing in the spec " all non-essential movement is removed" have led to questionable CSS advice on a variety of sites. Web authors are incorrectly assuming that people with vestibular disorders (or attention deficits) want all motion and animation stopped, and we have never found that 1. to be true, or 2. a great user interface choice.

How about this diff instead:

- minimizes the amount of movement or animation, preferably to the point where all non-essential movement is removed.
+ removes or replaces the types of motion-based animation that either trigger discomfort for those with vestibular motion sensitivity, or distraction for those with attention deficits.

[nattarnoff]

I'm all for the clarification. However, there are people who prefer no animation and currently the operating systems and the media-query don't allow that to be expressed. Any animation under 100ms is essentially invisible to the user, thus allowing us to have open/closed states and similar things to still be present (this is still animation, just super fast) even if we had a none option.

[cookiecrook]

@nattarnoff I can't tell if you're suggesting you want to keep the current language, or if you agree with my suggested changes, or something else. Will you please clarify? Thanks.

[nattarnoff]

@cookiecrook You language changes are good in my opinion.

What I was trying to point out is in the original discussions there was the concept of "none" with the query which never got implemented and I still see a need for.

Discount the second part for now. I'm going sit on it and will file a separate issue when I have my thoughts complete.

[cookiecrook]

Okay. I'm assuming "none" means "I want no motion whatsoever". Does this also mean "no animation whatsoever"? For example, a dissolve (aka "fade") is a motionless animation.

I think the current syntax is extensible enough so that a new value could be added at a later date, should any of the operating systems implement a "no animations whatsoever" feature. As you said, right now that setting does not exist, so there is no work to be done in CSS MQ.

[cookiecrook]

e.g. something like this

prefers-reduced-motion: [ no-preference | reduce | stop-all ]

where stop-all or something could be the additional future value if necessary.

[nattarnoff]

@cookiecrook That's exactly where I'm going and in my book it means all animation other than required by base HTML. Example being select has open and closed states and moving between them is an animation, but it is required by that element. It's also instantaneous (less than 100ms). But a 250ms+ fade animation would be stopped.

[Myndex]

Just to chime in here on this issue and a tangential one, as while excess motion can indeed be a problem for some people, there is also a reverse corollary.

Computers are now so fast that some changes in visual content happen in mere milliseconds, i.e. at a 60 Hz refresh rate, one frame or cycle is under 17ms. At this speed, a change can easily go unnoticed, and especially for those with vision impairments. Non-motion animation such as fade or blend transitions can help here, a well as other signaling methods.

I bring this up because it is once again an example of how accommodating needs are often conflicting.

How Fast is Fast

When editing a film, we commonly double-cut action, meaning when we make a cut in the middle of movement, we overlap the movement by four to five frames. At 24fps, this is about 160 to 200 ms, about the time it takes for the eye-brain visual system and cognition to recognize and settling into the abrupt change at the cut. The result is the action looks and feels smoother, whereas if the action was cut so it was realtime (same position of movement on the A and B side of the cut) it would tend to feel more jerky or even sped up (in fact that's an alternate editorial technique, undercutting so that some action is intentionally skipped to increase apparent speed).

This phenomena is more prevalent on the big screen in a theater than on a small video screen, though certainly noticeable on a 60" home theater screen.

State Change and Feedback

One key point here is making a distinction between distracting and enabling animation feedback.

An animation in an unrelated advertisement obviously falls under distracting. Also distracting would be blinking or self-moving elements intended to get you to click or follow a particular path unrelated to your current task. And yes these should be able to be shut off by the user. But these examples need to be separated from state-change feedback that is directly related to the content and/or task.

Certain cognitive/attentional issues certainly need the distractions turned off, but these same individuals ALSO may need the appropriate state-change feedback that is related to their current task turned ON. This is also an area where haptics and physical-object-model interfaces are very helpful.

Sound can play a useful alternate here too. Anecdotally, the sound failed on one of my laptops. Without the tiny feedback sounds of the OS, and coupled with my low vision issues (not to mention attention) I found I was constantly missing state changes, including loading whole documents with one of the text editors I use.

I literally do not see the change when it is ultra fast unless the change is high contrast and right in my fovea (central vision). Lower contrast peripheral changes go unnoticed unless that have either very high contrast or are timed to take longer.

TL;DR:

The point then is that if important state change and feedback animations are turned off, they may need to be replaced with an alternate to enable the same level of engagement and accessibility. And one of many areas where no single solution solves everyone's needs.

Andrew Somers W3 WAI Invited Expert Color Science Researcher

[marvindanig]

This is a very interesting discussion.

How do people with a vestibular disorder handle scrolling animation then? Does the current paradigm of scrolling webpages not affect them in any way? Or to put it in another way, will restricting content to live above-the-fold help if setting animations to zero or none is an absolute essential?

[nattarnoff]

@marvindanig Everyone is a little different, but from I've been able to research, it does affect folks but they live with it. There are some things we simply can't avoid. Some folks scroll rather slowly, others tend not to look directly at it. Given device variants, zoom, viewports, etc. there is no way to keep things above the fold. Scrolling is a natural part of using the web and something we accept as a need to work around.

[marvindanig]

No, I agree with you @nattarnoff.

I was just curious about how people with a really pronounced vestibular disorder deal with scrolling every day. And I think you are absolutely right about users looking away or "zoning out" for a bit when the content scroll-animates along the y-axis.

I feel that scrolling animation affects everyone on the planet and not just the folks with a vestibular disorder. It is subtle but also directly responsible for shrinking attention spans––text animating orthogonal to the reading direction kinda goes against the grain of saccadic perception in humans. Don't know if there is any research to back this up though.

[laukstein]

Question maybe not related here: When browser hardware acceleration is disabled, maybe it should behavior as prefers-reduced-motion: reduce? I am asking it because I notice more and more websites performing very badly when using animations, etc. when hardware acceleration is disabled, and I guess there currently are no way to identify it.

Here is a Chrome issue I open today related to performance issue when hardware acceleration off https://bugs.chromium.org/p/chromium/issues/detail?id=1264369

[frivoal]

I've included the rephrasings suggested by / discussed with @cookiecrook. Closing

Opened https://github.com/w3c/csswg-drafts/issues/6907 for the stronger variant suggested by @nattarnoff