Enhancement: [_animation.scss] add reduced motion support for .calcite-animate global CSS class

[caripizza]

Description

Add prefers-reduced-motion CSS media feature for the .calcite-animate global CSS class. This will ensure animations only apply when the prefers-reduced-motion media feature matches no-preference on a system (ie., the class will only animate if a user hasn't enabled "Reduce motion" on their system).

Proposed change (courtesy @tim-white-esri):

// because default state is opacity: 0; need to make sure that is explicitly set to 1
@media (prefers-reduced-motion: reduce) {
    .calcite-animate {
        opacity: 1;
        animation: none;
    }
}

@media (prefers-reduced-motion: no-preference) {
    .calcite-animate {
        opacity: 0;
        animation-fill-mode: both;
        animation-duration: var(--calcite-animation-timing);
    }
}

Acceptance Criteria

The src/assets/styles/_animation.scss global stylesheet includes the new CSS media features (above snippet) for the .calcite-animate class.

Relevant Info

See pr #2607 related file changes for helpful information on using the global class.

Which Component

n/a (global class)

Example Use Case

n/a

[tim-white-esri]

Any traction on this? I just received another complaint from a site visitor about animations not respecting reduced motion.

This is important for accessibility.

[geospatialem]

@tim-white-esri Thanks for re-pinging this issue. We'll be adding this to our upcoming sprint. This could be a workaround in the meantime.

[geospatialem]

The solution will update the internal duration factor based on user preferences. This will still give developers the flexibility to override the animation, but would not be supported by Calcite.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Experiencing some unexpected behavior in Windows with the loader component in beta.95 when animations are disabled. The expectation is no animation is present when users set the system preferences to disable animations.

Rerouting back to dev, @anveshmekala where this line could be causing the unexpected behavior.

beta.95 with unexpected behavior:

Prior to fix in beta.86 with previous animation:

[geospatialem]

Blocked by #5206.

Since the duration cannot be set to 0, the loader's animation is trying to finish in 3ms, which is way too quick.

We can either:

1. Hold off on 5206 to land so that this is fixed, or
2. As loader is not a openClose component yet, we could set it internally inside the loader host and remove after the 5206 fix.

cc @anveshmekala

[jkieboom]

Same experience as mentioned in #3489 (comment) on macos with the "Reduce motion" option enabled through Preferences -> Accessibility -> Display

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified on Windows and Mac OS when reduced motion is enabled in next.672 with the following Codepen.