I remember there were questions about how best to implement this feature. It's available to be used in CSS directly via media query, but it can also be used by appending a class to the body via JS.

I think the JS approach might suite our needs better because it allows us to frame the feature as an assertion rather than a negation.

Using the media query @media screen and (prefers-reduced-motion: reduce) would mean overriding previously declared animations and disabling them in that block.
The opposite of that would be placing the animation in a media-query like @media (prefers-reduced-motion: no-preference) but that has limited browser support.

Appending a class like .animations-enabled, which under the hood checks for @media screen and (prefers-reduced-motion: reduce) === false has the benefit of letting us default to true even when the browser doesn't support that media-query. The downside side is that it only kicks in when JS is enabled and the page has loaded, bu on the upside, it fixes the chrome animation flash bug! T234570

This could be added in mediawiki.page.ready since that is run in all skins.

Today we discussed this ticket at the end of standup and concluded that it was a bit too nebulous in its current form so we moved it back to needs analysis. Questions that came up during the discussion:

1. Where should we implement this change? E.g. Only in Vector, implemented in Core and used by Vector, implemented in Core and used by Vector and Minerva, etc?
2. Should we attempt to use the .animations-enabled class to replace the chrome animation flash bug. Is that part of the acceptance criteria? If so, will the prefers-reduced-motion media query work on desktop browsers and mobile browsers?
3. What is the acceptance criteria?

Pushing back to the backlog until we have this @Volker_E - the problem statement is not clear right now and this doesn't seem time sensitive given our existing work on search or languages.

I'm convinced we all would be better of, with this be done on a MediaWiki core (and possible duplication on external UI lib level) with a ruleset like this, carved out in sanitize.css:

@media ( prefers-reduced-motion: reduce ) {
  *,
  ::before,
  ::after {
    animation-delay: -1ms !important; /* 1 */
    animation-duration: 1ms !important; /* 1 */
    animation-iteration-count: 1 !important; /* 1 */
    background-attachment: initial !important; /* 2 */
    scroll-behavior: auto !important; /* 3 */
    transition-delay: 0s !important; /* 4 */
    transition-duration: 0s !important; /* 4 */
  }
}

Just relying on media query (as Less mixin) on every relatively big movement, mismatched direction or spatial distance animation/transition

This seems like the best approach to me here. I don't see why this needs to be generalized when it can be easily added to each feature where it makes sense using a simple media query.

Change 784332 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Disable animations when user prefers reduced motion

https://gerrit.wikimedia.org/r/784332

Being done as part of T306229:

Change 784332 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Disable animations when user prefers reduced motion

https://gerrit.wikimedia.org/r/784332

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Monterey
Browser: Chrome
Device: MBP
Emulated Device:NA

Test Artifact(s):

QA Steps

On OSX

Click reduce motion checkbox in accessibility system preferences
Visit a page as a logged in user and scroll down so the sticky header appears
✅ AC1: Expected - sticky header appears instantly without animation

Change 790765 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Make a11y rules universal to all skins

https://gerrit.wikimedia.org/r/790765

Change 790765 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.skinning: Make accessibility rules module universal to skins

https://gerrit.wikimedia.org/r/790765

https://gerrit.wikimedia.org/r/790765 is being deployed everywhere this week and will go into effect when a user has enabled the setting in their OS. One side effect I've noticed with this change is that, at least in Chrome and Safari, frames can be produced of the mobile sidebar that show it without icons/text for a short duration.

For example, the following shows a screenshot of the quirk in Chromium

Also see https://jmp.sh/jQwLhy7 which shows the effect in Safari.

I think this is related to the transition-duration property being 0.01ms. In the video, you can see that the flash/transition goes away if i set the transition-duration: 0ms. I think what is happening is that since these styles affect every element, the transition-duration property is > 0, and the default value of transition-property is all, elements can transition that wouldn't otherwise transition including the mobile sidebar's children.

We picked this up with our visual regression tests which are particularly sensitive to these changes and which previously used prefers-reduced-motion, but I have since removed prefers-reduced-motion from the tests as this effect makes them less consistent.

Change 793548 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.skinning: Amend prefer-reduced-motion accessibility rules

https://gerrit.wikimedia.org/r/793548

Change 793548 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.skinning: Amend prefer-reduced-motion accessibility rules

https://gerrit.wikimedia.org/r/793548

This makes progress bars and the like unintelligible.

No Motion Isn't Always prefers-reduced-motion | CSS-Tricks

User may try to workaround this with css hacks such as this one for the sticky header:

#vector-sticky-header {
transition-duration: 0ms;
}

@Xaosflux The sticky header already does not animate if prefers-reduced-motion returns true, thanks to the patch associated with this task.