Page MenuHomePhabricator

Add ability to take `prefers-reduced-motion` user setting into account in Vector
Closed, ResolvedPublic

Description

prefers-reduced-motion media query sees increasing operating system and browser support and should be taken into account for all user-interface transitions and animations to address people with vestibular disorder needs (global estimation of around 70 million people).

Possible implementation paths

  • Adding a core style module that is either loaded by default or as an opt-in for skins and by default by installer(?)
  • Adding a specific CSS class to body as core functionality when user hasn't set @media screen and (prefers-reduced-motion: reduce);
  • Just relying on media query (as Less mixin) on every relatively big movement, mismatched direction or spatial distance animation/transition

Prior work

This has been discussed before in context of

External references

QA

On OSX

  • Click reduce motion checkbox in accessibility system preferences

Screen Shot 2022-05-03 at 11.07.09 AM.png (998×1 px, 355 KB)

  • Visit a page as a logged in user and scroll down so the sticky header appears
  • Expected - sticky header appears instantly without animation
  • Untick the reduce motion checkbox
  • Visit a page as a logged in user and scroll down so the sticky header appears
  • Expected - sticky header appears with animation

QA Results - Beta

ACStatusDetails
1T254399#7901742
2T254399#7901742

QA Results - Prod

ACStatusDetails
1T254399#7919414
2T254399#7919414

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
ovasileva triaged this task as Medium priority.Jun 9 2020, 1:20 PM
ovasileva added a project: Readers-Web-Backlog.

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

Jdlrobson renamed this task from Add ability to take `prefers-reduced-motion` user setting into account to Sidebar: Add ability to take `prefers-reduced-motion` user setting into account.Jul 28 2020, 6:20 PM

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 */
  }
}
Volker_E renamed this task from Sidebar: Add ability to take `prefers-reduced-motion` user setting into account to Add ability to take `prefers-reduced-motion` user setting into account.Feb 22 2021, 4:52 PM
Volker_E updated the task description. (Show Details)
LGoto added a subscriber: LGoto.

This task was closed as part of backlog upkeep. If you believe it was closed in error, please respond on the ticket.

This is an important Accessibility feature and should just be removed from Readers-Web-Backlog, not declined.

Jdlrobson renamed this task from Add ability to take `prefers-reduced-motion` user setting into account to Add ability to take `prefers-reduced-motion` user setting into account in Vector.Aug 2 2021, 10:56 PM
Jdlrobson moved this task from Triaged but Future to Tracking on the Readers-Web-Backlog board.

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

Change 784332 merged by jenkins-bot:

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

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

Edtadros added a subscriber: Edtadros.

I'm not sure what to validate here.

Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)

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

Screen Recording 2022-05-03 at 7.03.18 PM.mov.gif (496×1 px, 1 MB)

Untick the reduce motion checkbox
Visit a page as a logged in user and scroll down so the sticky header appears
✅ AC2: Expected - sticky header appears with animation
Screen Recording 2022-05-03 at 7.03.44 PM.mov.gif (496×1 px, 2 MB)

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

Test Result - Prod

Status: ✅ PASS
Environment: enwiki
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

Screen Recording 2022-05-10 at 4.17.08 PM.mov.gif (632×804 px, 1 MB)

Untick the reduce motion checkbox
Visit a page as a logged in user and scroll down so the sticky header appears
✅ AC2: Expected - sticky header appears with animation

Screen Recording 2022-05-10 at 4.17.33 PM.mov.gif (632×804 px, 1 MB)

Looks good, resolving

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

MediaWiki_Test_minerva_mobile_mainmenu-open_0_viewport_1_tablet (1).png (768×720 px, 27 KB)

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.

Options:

  • Revert patch. Given the small amount of transitionend usages and its the very specific and limited scope in balance to the importance of the feature for folks in need, we should rather
  • continue with module and observe user feedback and amend module when needed. One other simply scoped amendment is described in T308705.

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