Description
easemotion-css provides a fantastic, lightweight collection of transition and animation utilities. However, dense web animations can cause vertigo or motion sickness for users with vestibular disorders.
To ensure the library is production-ready for modern, accessible web development, we should introduce built-in support for the CSS @media (prefers-reduced-motion: reduce) query. This will gracefully disable or tone down heavy transitions for users who have requested reduced motion at the system level.
Proposed Solution
We can leverage a CSS variable or a global utility class reset that automatically dampens, slows down, or entirely disables animations when a user has "Reduce Motion" enabled at the system level.
For example, appending a global block to the framework's core CSS stylesheet:
CSS
@media (prefers-reduced-motion: reduce) {
*,
::before,
::after {
animation-delay: -1ms !important;
animation-duration: 1ms !important;
animation-iteration-count: 1 !important;
background-attachment: scroll !important;
scroll-behavior: auto !important;
transition-duration: 0s !important;
transition-delay: 0s !important;
}
}
Alternatively, we could allow minor, non-disruptive opacity fades to persist while stripping out heavy positional shifts (like bounces or slide-ins).
Why this is valuable to the framework
Accessibility (a11y): Aligns easemotion-css with modern web standards (WCAG 2.1).
Competitive Edge: Many animation libraries ignore accessibility; built-in reduced-motion handling makes this framework highly viable for corporate and enterprise open-source projects.
Zero Dependencies: Keeps the project lightweight and pure CSS.
Execution Plan
I would love to claim this issue! My plan is to:
Identify the core animation styles.
Implement a balanced global override or utility classes using @media (prefers-reduced-motion: reduce).
Test the implementation across multiple components to ensure styling layouts don't break when animations are suppressed.
Description
easemotion-css provides a fantastic, lightweight collection of transition and animation utilities. However, dense web animations can cause vertigo or motion sickness for users with vestibular disorders.
To ensure the library is production-ready for modern, accessible web development, we should introduce built-in support for the CSS @media (prefers-reduced-motion: reduce) query. This will gracefully disable or tone down heavy transitions for users who have requested reduced motion at the system level.
Proposed Solution
We can leverage a CSS variable or a global utility class reset that automatically dampens, slows down, or entirely disables animations when a user has "Reduce Motion" enabled at the system level.
For example, appending a global block to the framework's core CSS stylesheet:
CSS
@media (prefers-reduced-motion: reduce) {
*,
::before,
::after {
animation-delay: -1ms !important;
animation-duration: 1ms !important;
animation-iteration-count: 1 !important;
background-attachment: scroll !important;
scroll-behavior: auto !important;
transition-duration: 0s !important;
transition-delay: 0s !important;
}
}
Alternatively, we could allow minor, non-disruptive opacity fades to persist while stripping out heavy positional shifts (like bounces or slide-ins).
Why this is valuable to the framework
Accessibility (a11y): Aligns easemotion-css with modern web standards (WCAG 2.1).
Competitive Edge: Many animation libraries ignore accessibility; built-in reduced-motion handling makes this framework highly viable for corporate and enterprise open-source projects.
Zero Dependencies: Keeps the project lightweight and pure CSS.
Execution Plan
I would love to claim this issue! My plan is to:
Identify the core animation styles.
Implement a balanced global override or utility classes using @media (prefers-reduced-motion: reduce).
Test the implementation across multiple components to ensure styling layouts don't break when animations are suppressed.