[policy, no patch] Use "prefers-reduced-motion" media query to disable animations

Added Windows 7 and up as having a reduced-motion preference.

Just noting from an experience today with a new interface that even very brief (sub-second) animations can set me off if they take up a sufficiently large portion of the screen (in this case, about 50% but it was the 50% in the middle and which I was focusing on).

Thanks for tagging this issue for your sprint in Ukraine, Ivan. I'll be taking part in the Global Sprint weekend too, working at the Leeds, UK meeting. I'll be reviewing & mentoring with accessibility issues, and will be available via the Drupal Slack #accessibility channel.

The idea here is to build guidelines, as a [policy,no patch] issue. I've updated the issue summary to clarify this.

If you'd prefer to dive into CSS code, you could work on the animations in the Batch API progress bars, or the Settings Tray module. Please open child issues for those - I've included placeholders in the remaining tasks section.

We still need to update the issue summary to describe the problem better. It would be a good idea to look back over the previous issue #2316205: Provide a way to disable animations for a11y for relevant points we want to keep.

The core ideas/plan queue is the appropriate place for this just now.

#2940677: Support prefers-reduced-motion in off-canvas dialog created

I've changed the example in the summary to use the more verbose prefers-reduced-motion: reduce.

This matches what has been done in #2940012: Use prefers-reduced-motion media query on batch progress bar and is clearer on what is being checked.

Fleshing out he summary - links to related issues, a few more todo items.

In #2940012: Use prefers-reduced-motion media query on batch progress bar, @John Cook noticed that Opera is a bit fussy about transition: none, and seems to need -o-transition: all 0 none or transition-duration: 0s;.

Details in this StackOverflow page: https://stackoverflow.com/questions/6634470/disable-turn-off-inherited-c...

Adding this potential WTF to the issue summary.

Just adding this new link to this topic https://hugogiraudel.com/2018/03/19/implementing-a-reduced-motion-mode/

I've found in some a11y best practices around the web that this could be handled globally as follow (vendor prefixes to be added):

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
  }
}

I think we should think about getting this code in Core to send a strong message about these issues AND avoid to fix all animations and transitions of Core one by one.

Thanks @DuaelFr - that's a really exciting idea. I like part about "sending a strong message about these issues".

I grabbed this from our chat in #accessibility channel on Drupal Slack today (slightly edited.)

andrewmacpherson [9:00 AM]
I'm not sure about the `important!` bit.  If we can avoid that it would be better.  Because it would could limit a someone who had a userstyles, and actually wanted some animation on certain elements, like a slight animation on focus style to help follow it around.

DuaelFr [9:01 AM]
The thing is that if we don't add `important` this rules are going to be overriden by any other CSS rule as the "*" selector has a very low score

andrewmacpherson [9:01 AM]
right.
there might also be some places where we want to have an animation, if it's deemed low risk.  e.g. a small progress thobber.

DuaelFr [9:03 AM]
small throbber is only small for people that doesn't use a huge zoom :slightly_smiling_face:

andrewmacpherson [9:04 AM]
I know :slightly_smiling_face:

also, e.g. on the settings tray, this patch proposes to kill the big animated slide-in, but keep some slight animations on button background colour.  #2940677: Support prefers-reduced-motion in off-canvas dialog

DuaelFr [9:05 AM]
I don't know people that suffer VIMS but we should ask them
Is that opacity transition really important?

andrewmacpherson [9:06 AM]
If you can find them!  We know Charles in the issue queue.  A big difficulty is in finding people in our community with disabilities and/or assistive tech.  We have to wait for them to self-identify.
My view is we'd kill all animations.  I've been thinking about a principle: "Designs shouldn't rely on animations".  Just like they shouldn't rely on colour.

Throbbers don't make me sick but they distract me. I'd really prefer no animation.

If someone is telling you they don't want animation (through the setting), the best practice would be to not have any. The old-school stationary word "Loading..." is sufficient.

If someone is telling you they don't want animation (through the setting), the best practice would be to not have any.

It's confusing that the media query, and settings in the UI, called it "reduce motion". That's different from "kill all animation".

I'm also strongly in favour of treating reduce-motion as no animations at all, as a policy. It's just easier if we don't have to triage them as high or low risk, which would lead to bikeshedding.

I'm guessing the wording came from iOS and macOS, where, at Settings > General > Accessibility for iOS and System Preferences > Accessibility > Display for macOS, the setting label reads "Reduce Motion." About the reduce motion setting, Apple Human Interface Guidelines reads:

Make animations optional. When the option to reduce motion is enabled in accessibility preferences, your app should minimize or eliminate application animations.

On the PC, where, alas, no browsers yet support it, at Control Panel > Ease of Access Center > Make the computer easier to see, the setting label reads "Turn off all unneccessary animations (when possible)" which is much clearer.

That said, the throbber, over and above being an unneccessary animation, comes under the category of animations (potentially) lasting longer than 5 seconds. Animations longer than 5 seconds are supposed to, under WCAG 2.0 AA, have a pause button. That would be odd for a throbber, so it would be better to just not animate it as an unneccessary animation if Reduce Motion or Turn off all unneccessary animations is enabled.

In general, huge +1 to this issue. Looks like the selector is already supported by Firefox 63 nightlies for Windows and may come to Firefox for Mac soon after. As far as I know, I don't have VIMS, but I personally dislike most web animations, so I may well switch from Chrome to Firefox in order to improve my web browsing experience via this setting.

https://www.w3.org/TR/WCAG21/#dfn-motion-animation distinguishes motion animation from non-motion animations:

For example, an element which moves into place or changes size while appearing is considered to be animated... Motion animation does not include changes of color, blurring or opacity.

Therefore, do we want "prefers-reduced-motion" queries to remove only motion animations, but leave in-tact color, blur, and opacity animations? In which case, do we want a loading throbber animation that only animates those properties?

I understand that some people dislike all animations, but is the scope of this issue to cater to that preference, or to respect the fact that the selector is named "prefers-reduced-motion" rather than "prefers-zero-animation"?

@effulgentsia - Thanks for the update about Firefox implementation.

In which case, do we want a loading throbber animation that only animates those properties?

Good idea, that's worth a child issue for sure! This could be something we do in the new Admin UI (replacing the Seven theme). Over in one of the Admin UI planning issues, I suggested that if the new theme targets WCAG 2.1, then we might not need to commit to addressing all the new WCAG 2.1 Success Criteria in Seven. The current thobber is in core/misc, so I wouldn't expect to be able to change that before D9. However: bonus points if a new throbber in Admin UI also takes Bartik/Seven into account.

Animations from Interactions is level AAA, and the thobbers might be classed as "essential" for an exemption. This is still worth doing though. We can also consider the WCAG 2.0 "Pause, Stop, Hide" at level-A - In the case of busy throbbers, they have an indefinite duration. Especially in the case of AJAX autocompletes, etc., they could easily go over the 5 seconds for this criteria. But here again, they arguably get the "essential" exemption. I like Charles's about a stationary "loading" word, so the indicator doesn't solely rely on animation to convey what's happening.

remove only motion animations, but leave in-tact color, blur, and opacity animations?

Now, it would still be possible to create motion animations using just those properties. For instance, the classic radial-spokes thobber designs work by fading individual lines in and out, in sequence, which adds up to an effect like spinning clock hands.

I understand that some people dislike all animations, but is the scope of this issue to cater to that preference, or to respect the fact that the selector is named "prefers-reduced-motion" rather than "prefers-zero-animation"?

Mmm, I keep swaying from one side of the fence to the other on this point. For me it hinges on how we assess them; it's not clear to me where (or if...) we can draw a threshold for high-risk vs. low-risk animations. (I think that's how "Animations from Interactions" ended up being demoted from level-AA to to level-AAA during the WCAG 2.1 Working Drafts.) The zero-animation outlook removes this tricky judgment call, makes triage easier, and provides a clear design constraint.

The Windows 10 preference simply states "Show animation in Windows" (yes/no). So that would imply No=Don't animate at all.

Split the Firefox issue link into two links to reflect Bugzilla bifurcation of the issue by operating system.

Noted impending availability of the media query in Firefox 63 for October 23, 2018.

Re: #30 - thanks Charles, that's a really useful point. So, we should consider that the phrasing on the OS preferences UI sets user expectations.

I'm excited to try the firefox nightly now.

Meanwhile, I found the upstream issue to implement it on Firefox for Android too.

I tried the Firefox Nightly 63-alpha1 with Windows 10, and saw it working!

I confirmed it was working with:

• Drupal 8.6 batch progress bar (introduced by #2940012: Use prefers-reduced-motion media query on batch progress bar
• The reduced motion demos from the WebKit blog.

As Charles reports, the media query is tied to the OS-level "Show animations in Windows" user setting. They have different names depending on which version of Windows it is:

• "Turn off all unnecessary animations (when possible)" user setting in Windows 7.
• "Show animations in Windows" user setting in Windows 10.

Started re-organizing the issue summary.

This is moving along well. The progress on browser implementation is encouraging, and WCAG 2.1 is finalized. The batch progress bar has been fixed as a proof-of-concept, and we have other insights about throbbers, catch-all CSS rules, and guiding design principles. Plus a should-resolve question over the reduce-motion vs kill-all-motion approach.

We're at the stage where we can turn this into a policy, which other contributors can follow. So the next step is to tidy this up, so we can present it as something which is workable and justified.

The throbber design is definitely worth a child issue - @Charles would you like to start that off, perhaps? I think the JS + Admin UI initiative team would appreciate a clear statement of that problem.

Android 9 introduces an OS accessibility preference called "Remove animations". Perhaps Firefox for Android will tie the media query to that? We'll learn soon enough.

Source: Android 9.0 Pie accessibility hands-on, and lots of other articles. It's getting mentioned in quite a lot of those "10 hidden features in Android 9" hype articles.

re: the throbber, just adding a related issue so we don't lose it

I took part in a design call today with the #admin-ui initiative, for the new design system and admin theme refresh. We talked about having a busy/loading indicator with a fallback for prefers-reduced motion!

One idea was for an autocomplete ajax text box. It would have a rotating icon inside the textbox, and a "Loading..." message would appear as small text just outside the text box. With prefers-reduced-motion, the icon animation would be killed, and just the stationary "Loading..." message would appear.

prefers-reduced-motion has apparently landed in Firefox for Android now, and will ship with v64 in December 2018, according to Firefox 64 for developers release notes. I'm not clear if it requires the new "remove animations" OS-level accessibility setting in Android 9? (I couldn't make it work in Android 8.)

It also landed in Firefox for Mac in v63, according to Firefox 63 for developers release notes.

I dropped by the Mozilla offices in Toronto this week & had a great chat with some of their accessibility folks. Pretty sure VIMS came up. Happy that prefers-reduced-motion has landed in FF.

Thanks for the update @andrewmacpherson

Just adding this link about toggling animations:
https://www.kirupa.com/html5/toggling_animations_on_off.htm

According to #30 / #34, Windows 10 labels the setting "Show animations in Windows".

According to #40, Android 9 labels the setting "remove animations".

Yet the link in #42 says:

...what is the right behavior when someone specifies that they want to see fewer animations. The answer isn't always to disable all animations. Doing so may actually hinder the usability of your app greatly. This is where testing with real users who may have visual/motion-related disorders can be helpful. On iOS, when you enable the setting to reduce animations, what happens is that each animation effect is adjusted different. Zooming effects get turned into more subtle fades. Parallax effects, on the other hand, are fully disabled. The main takeaway is that you need to be thoughtful about how you handle a user's preference for reducing animations.

And https://webkit.org/blog/7551/responsive-design-for-motion/ has more info on that as well.

So I'm eager to see how this all gets synthesized into recommendations for Drupal.

For clarification, animation sensitivity isn't just about VIMS. It can also be about hypervigilance or, for that matter, preserving battery life.

As of January 9, 2019, Chrome has committed to implementing and shipping this feature.

blink-dev › Intent to Implement and Ship: CSS prefers-reduced-motion media query

Chrome Platform Status > CSS prefers-reduced-motion media query

Issue >Add support for CSS prefers-reduced-motion media feature

I made a couple of updates to the issue discussion.

In the Todo, I raised the question of whether animations triggered by cursor movement could inadvertently trigger epileptic seizures by producing flashing within the rate specified by WCAG 2.0 Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures. I add this because I was recently presented with a design which involved multiple color-inverting flipping tiles on hover. Given sufficiently fast cursor movement, this could result in more than three flashes per second.

I added a link to a second reference article, from A List Apart, as discussion of vestibular disorder.

As a comment on the Webkit article, they recommend only removing animation if it is known to trigger vestibular disorder. I disagree, in that, as noted, other disorders can be triggered as well, and most people would not have the expertise to know whether a particular animation would trigger someone.

Following up on @Charles Belov's post. Looks like Google's Chrome will have this enabled by default in release 74:
https://developers.google.com/web/updates/2019/03/prefers-reduced-motion

Chrome 74 has been released. I've confirmed with the Webkit prefer-reduced-motion demo that prefers-reduced-motion is supported.

Corrected typo "loose" for "lose"

The only outstanding question here is about treating "reduce" as "remove/turn off". We've been back and forth on this a lot.

To my mind, the overriding factor is that the majority-share OS (Windows and Android) convey it as "remove". However, it occurred to me to check what the CSS Media Queries level 5 working draft actually says. Today I noticed this definition (emphasis mine):

`reduce`
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.

That wording seems to settle it. We've already seen how the OS-level preferences are phrased, so the expectation of the majority of users will be to remove (not reduce) animations. The wording of the CSS definition aligns with this too.

So, I propose we move this policy to the finishing line:

• Designs for Drupal themes and components can make sensible use of animation to aid understanding.
• Designs should not rely on animation, and are still understandable and operable when animation is turned off.
• Treat prefers-reduce-motion: reduce as meaning "completely remove", per the CSS definition, and in harmony with how the user preference is actually called on most OS.
• Recommend themes turn off all animation (using a global selector) as the simplest and most robust approach. Components which warrant an exception (hopefully rare) can explicitly override this. Include a specimen CSS rule.
• Update the suggested background reading. Browser/OS support notes, CSS spec, design articles, disability articles.

I'll update the the issue summary so it reads like a policy.

This comment updates the sections on supported browsers and OS preferences. Most have implemented it now.

Added note on iOS splitting out the preference for slide-in menus. I don't know whether macOS Catalina similarly implements a split-out preference, but, as they came out around the same time, I would not be surprised if this has been done. Given that this is not currently supported by any browser nor implemented in Windows, I suggest we focus on prefers-reduced-motion as the sole arbiter.

As for necessary animations, and I imagine there are some, those would need to respect Pause, Stop, Hide. I added a TODO on whether we want to disallow autoplay when prefers-reduced-motion is set to reduce. I know autoplay is an issue for me.

I would caution against completely removing the animations (as suggested in #23).

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
  }
}

This would cause any transitionend and animationend events not to fire. I personally use these events for setting focus to a textfield after something slides in.

A better way (assuming the decision is made to implement this) would be to use an "almost 0s" duration

 animation-duration: 0.001s !important;
 transition-duration: 0.001s !important;

That all being said, I strongly suggest that we read through this Mozilla github issue: https://github.com/mozdevs/cssremedy/issues/11

There's a ton of research done on this very question. Val Head (who is a very respected authority on web animations) added

This is definitely a more complex problem than it initially seems as has been stated above. In my research so far I haven't found a blanket solution that isn't without issues.

Thanks @mherchel.

I too have seen the approaches with 1ms duration, and the issue of whether transition events fire. I was meaning to raise this myself, which is why I haven't put the transition: none snippet into the issue summary yet.

Thanks for the github issue. There's a lot of detail there. I have a few other bookmarks which cover this, but not in as much depth.

I've heard some reasonable uses for JS transition events, and if they don't fire because of transition:none I expect that would complicate a lot of JS. In particular, I've seen approaches which update dynamic ARIA properties on transitionstart.

The 1ms approach sounds better based on what I've heard so far.

From the mozdevs/cssremedy Github issue mentioned by @mherchel in #52 ( What's best for prefers-reduced-motion?)

This is definitely a more complex problem than it initially seems as has been stated above. In my research so far I haven't found a blanket solution that isn't without issues.

Yes, I'll buy that. The Github issue (particularly Val Head's comments) go into greater depth than I've ever considered. I'm not an animation designer, and some properties discussed there are beyond my present knowledge (e.g. animation-fill-mode). However, what @DuaelFr and myself are proposing is a safety-oriented baseline for common animation uses, not a single rule for all situations. Specific components could still over-ride this baseline.

Also from the same Gitub issue, some quotes from our old friend Jen Simmons who is thinking along the same lines (emphasis mine)....

I'm left thinking we should include this in Remedy, not because the CSSWG "got it wrong", but because this is a good default for all of the web developers (Authors) who don't bother thinking about prefers-reduced-motion at all. It gives people who need animations eliminated or reduced what they need. And while this might potentially 'break' some UX, developers can easily fix those less-frequent cases by overriding Remedy's code [...]

The other choice is to not do this at all. To leave it all up to the developers. I just don't like that. I'd rather risk breaking fancy animations than risk no websites bothering to write good code for people who can't take motion very well.

Jen Simmons was the original Bartik theme designer/maintainer, so she knows our situation well! (Heck, CSSRemedy sounds like the sort of library any major CMS might consider adopting wholesale, like we do with normalize.css).

The main purpose of such a baseline in Drupal core themes (and hopefully contrib base themes and starter kits) is to safeguard against CSS animations in contrib/custom modules where the developer hasn't supported prefers-reduced-motion. For example, a contrib module might provide an alternative admin UI geared towards managing large taxonomy trees; with a progressive tree-disclosure widget which animates the max-height when a deeper level is opened. Such a case would work fine with the sort of global baseline proposed here, and the module maintainer wouldn't have to do anything special.

FWIW, Bootstrap went for transition: none, and consequently Joomla has that too:

  @media screen and (prefers-reduced-motion: reduce) {
    transition: none;
  }

The Bootstrap issue queue gives some insight into how this was received among developers: Bootstrap issues containing "prefers-reduced-motion".

As each new browser implemented prefers-reduced-motion (first Safari, then Firefox), new bugs were filed to say some Bootstrap component was broken. In most cases it was deemed "by design", and developers had just run into the global baseline prefers-reduced-motion for the first time.

When we put a similar baseline into core Drupal themes, we might expect a similar run of issues in contrib modules. That's OK - I'd view it as an opportunity to raise awareness of the issue among developers and themers. Most users won't encounter it unless they have turned the OS preference on.

Note that core themes are marked as "internal" so this is fine for backwards-compatibility policy. I think it should be implemented directly in Bartik, Seven, Umami, and Claro, but NOT Classy because many live websites are using that. In any case there's a plan to remove Classy in D9.

Nonetheless, this policy warrants a change record and handbook page.

@Charles Belov, re. #51:

Thanks for the note on iOS 13 "Prefer Cross-Fade Transitions". My iPod Touch isn't eligible for iOS 13 so I haven't seen that yet. However, does it actually have an effect on web content? Unless it's something that we can address in Drupal, then it's out of scope here.

SOME instances of WCAG "Pause, Stop, Hide" and "Three flashes" might be caught by the prefers-reduced-motion baseline we propose, but only if the animation is implemented using CSS animation/transition. My expectation is that most occurences of the these will come from content such as video, or custom JS slideshows etc. These are the sort of thing the baseline won't catch.

We can certainly advise developers and authors about it in this policy and in the accessibility handbook pages. This policy issue title could be a bit more general, e.g. "Guidance on safe use of animation".

I added a TODO on whether we want to disallow autoplay when prefers-reduced-motion is set to reduce.

This might be possible, but I think it's going to hard to catch in a generic approach. Speculation:

• The core audio and video file field formatters have a setting for the HTML autoplay attribute. We could attach some JS to those, with a matchMedia() check for prefers-reduced-motion, to turn the HTML autoplay attribute off. Perhaps explore this in a follow-up issue?
• Third-party JS media players, slideshows, etc., are too diverse in their implementations for us to fix. It's probably better to file issues with the upstream projects.

@andrewmacpherson: Thank you for your detailed response.

Prefer Cross-Fade Transition replaces menu and dialog box slide-in with a fade transition. That menus and dialog box slide-ins were not previously included in Prefers Reduced Motion had been raised as a justification for not including all cosmetic animation under Prefers Reduced Motion. I'm not sure why Apple chose to break it out, but it is clear that it bothers enough people (myself included) that Apple chose to address it.

Prefer Cross-Fade Transition for menus/dialogues is not currently relevant to any browser implementations in any implementable way, so far as I know, so I'm not suggesting it be added to the scope. It was included more as an indicator of where the industry is heading in terms of best practices. Since we can't implement it, I suggest that we treat prefers-reduced-motion: reduce in Drupal as if it included an identical choice for Prefer Cross-Fade Transition.

However, Prefer Cross-Fade Transition does point the way to a possible solution for dealing with not being able to fully disable transition through transition:none. That is, where there must be some kind of transition, implementing it as a cross-fade rather than as motion.

Treating "motion" separate from animation or transition is splitting hairs. The CSS definition talks about "movement or animation" in one breath, and the user preference name on Windows and Android refers to "animation" not motion. It's clear that the intention of the media query is to turn off animation in general.

Apple != "the industry".

There is also a prefers-reduced-transparency media query in the CSS draft too, but I don't think that's been implemented yet. An animated cross-fade could count as animation and transparency; I think you'd turn it off if either media query matched.

Tagging for accessibility.