Use `prefers-reduced-motion` Media Query on auto-updates spinner animations

[audrasjb]

Animations used for auto-updates spinners should take into account browsers preferences.

For these animations, a prefers-reduced-motion: reduce Media Query should be used, with the animation CSS property set to none.

For reference: https://core.trac.wordpress.org/ticket/51476#comment:17

[xkon]

52263.diff​ adds the prefers-reduced-motion media query for the spinners as well as an extra query for the #51476 (not yet committed) admin bar spinner since we're adding an animation there as well.

Tell me if you prefer to update the reduced motion on the other task for the admin bar and I can refresh this :).

[audrasjb]

Hey, thanks for the patch @xkon, looks good to me! 👍
Let's wait for #51476 to be committed then :)

[johnbillion]

Note that "reduced motion" doesn't mean "no motion". Personally I would classify a loading spinner as useful motion that assists in communicating the current state of the application, as opposed to animation that is purely decorative.

WCAG AAA talks about "unnecessary animation" in this context too: ​https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html

If this spinner isn't animated when prefers-reduced-motion is in use, does it convey its meaning well enough?

[audrasjb]

@johnbillion fair point, thanks.
Given there is a state change on the action link (the link text changes once auto-updates are activated/disabled), I think it's ok to remove the animation, because we actually provide a feedback to the user (in the link text and also in a wpa11y.speak notice).

[audrasjb]

Patch is ready to go on my side :)

[SergeyBiryukov]

In 50028:

Accessibility: Administration: Respect the prefers-reduced-motion media query for update icon spinner animations.

The update icon rotation should not occur when the user has opted to reduce motion, for example by selecting the "Reduce motion" option in macOS' preferences or unselecting "Show animations in Windows" in Windows' preferences.

Follow-up to [47813], [50027].

Props xkon, audrasjb, johnbillion.
Fixes #52263. See #51476.

[sabernhardt]

Plugins screen with one plugin updating and others with update available

[sabernhardt]

restoring motion for Ajax plugin update actions (only)

[sabernhardt]

I think we should reconsider disabling every spinner rotation, and particularly maintain motion in places where the icon is both visible and static before you click to update plugins with Ajax:

1. The "Update Now" buttons on the Add new plugin (or theme) screen
2. The update message after clicking "update now" for individual plugins on the Plugins screen

In those cases, I would consider the motion "essential" to convey the busy state visually. 52263.1.diff​ restores spinning for both.

Leaving the other icons motionless by user preference:

• I specifically wanted to avoid adding extra motion in the toolbar, away from the interaction, so of course I'd like to keep that part of [50028].
• The auto-update buttons complete the action so quickly that motion might be more distracting than helpful for some users.
• The Import page's spinner icons only show while the install process is running, so the icon's presence is likely enough to help indicate the status (along with the text).
• I was a bit surprised the first time I installed a plugin or theme and the Install Now button icon did not rotate. The process there takes longer to finish, and the motion is meaningful. Yet it may not be essential because the icon appears and disappears the same way as the Import installer and auto-update buttons.

[sabernhardt]

After discussion on the #accessibility Slack channel, we agreed it's better to keep the original changeset as it is.

@joedolson summarized the points regarding motion:

It could hypothetically be useful, but because the expected result of reducing motion should be to ... reduce motion, we should start [by] respecting that expectation.