[rikroots]

I agree - prefers-reduced-motion is a user-controlled OS-level setting (like prefers-color-scheme) which apps and websites should do their best to respect.

Sadly we live in a world where developer time is a cost, and the cost of respecting user preferences is way down the list of things to spend cash/time on ... unless, of course, an A/B test showing that common courtesy leads to better conversions gets deployed and runs to significance.

Saying that, I don't believe we should give up on the fight to better respect our users' preferences. For my part, I've designed my JS library in a way to make it as easy as possible for developers to build interactive 2d canvas-based graphics that are as respective of user choices as possible[1][2][3]. If nothing else, it demonstrates to other developers that such things are not impossible to achieve.

[1] - https://codepen.io/kaliedarik/project/full/AMVKPx - Accessible stacked bar, and line, charts

[2] - https://codepen.io/kaliedarik/project/full/AzWnNa - Header text colorise and animate effects (respects prefers-color-scheme, prefers-reduced-motion, etc)

[3] - https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson - tutorial on how to make the 2d canvas more accessible/respective of user choices

[xigoi]

If you're so tight on time that you can't add a simple wrapper to your CSS rule, why bother with adding animations at all?

[kiawe_fire]

It’s often not a matter of “add a wrapper to this one CSS rule” but rather, “add a wrapper to ALL of these rules and some of this inline CSS scattered everywhere”.

This is why, as part of a baseline of proper software engineering, it’s so important to get into a configurability/feature flag mindset, right from the start.

If every feature is treated as something toggleable - if every color and padding value is a variable, and every visible string of text is wrapped in a function call that just returns the string, right from the start, then things like turning off animation, making colors more contrasting, or translating on-screen text to another language becomes magnitudes simpler when you do need it.

This is where I have a problem with the pervasiveness of the YAGNI mindset. So many of these things fall right onto the YAGNI sword.

Sure, you can get carried away with premature optimization, for example, but there are so many simple habits developers can and should develop that, once established, will add virtually no time or complexity to what you’re building but will save time and complexity in spades later on.

And if you truly “ain’t gonna need it”, then you still benefit from a more disciplined code structure.