Support prefers-reduced-motion

[CharlesBelov]

Motivation

Please change your product so that prefers-reduced-motion is automatically supported. Specifically, if the browser indicates that the site visitor has specified that they don't want animation, flyTo, jumpTo, and easeTo would automatically not animate the transition, but simply display the new view. Chrome, Firefox, and Safari support this setting.
This is important because these effects can make some people, myself included, feel ill. That's probably not something you want associated with your product.

The advantage is that you can still provide animation for people who are not bothered by it without making people who are bothered by it feel ill.

Design Alternatives

This could be accommodated by querying the CSS media query prefers-reduced-motion. This is currently supported in Firefox, Chrome, and Safari.

The no-change option would be to expect websites to reduce animation for everyone or else leave people to learn to avoid a website if it makes them feel ill.

Design

Mock-Up

What will this design look like to developers?

The intent is that MapBox would implement this feature automatically so that developers do not need to be concerned with it.

What will this design look like to end users?

If an end user has set their operating system to reduce or eliminate animation, then maps will always go from one state to another with no movement transition.

If an end user has not set their operating system to reduce or eliminate animation, then maps will display with whatever movement transition the developer has programmed.

Concepts

How will we teach this design?

Since this would be implemented universally, no training would be needed. That said, you might link to an article on the subjects such as https://alistapart.com/article/designing-safer-web-animation-for-motion-sensitivity/ (warning: some people have reported that the image at the top of this article triggers symptoms similar to those caused by animation)

What terminology will work best for the new concepts introduced by this design?

vestibular disorders
prefers-reduced-motion

What existing precedents support the new concepts?

https://www.drupal.org home page detects prefers-reduced-motion in supporting browsers and either animates or not depending on that setting.

Where do the concepts set new precedents?

None, although this is an emerging best practice.

Implementation

How you would implement the design in Javascript?

If prefers-reduced-motion is set to reduce,
then transition between two map states without animation.

How you would implement the design in C++?

Same pseudocode.

What parts of the Mapbox GL ecosystem will need to change to accommodate this design?

flyTo, jumpTo, and easeTo

Are there any important edge cases?

There is disagreement on how to handle browsers which do not support prefers-reduced-motion, such as IE or Edge. Some recommend treating such browsers as requesting no animation; some provide the animation.

[andrewharvey]

I'm slightly in favour of GL JS handling this so developers don't need to write a whole bunch of special cases. If someone has configured their browser to prefer reduced motion, we should respect that by default.

https://developers.google.com/web/updates/2019/03/prefers-reduced-motion shows how to detect this setting via a standard API with JavaScript.

• jumpTo should already be unanimated, it should just be flyTo, easeTo, panBy
• map.fadeDuration (fade-in/fade-out animation for label collisions)
• runtime styling transitions/cross-fading

[mourner]

I agree we should support this. In camera.js, there are a few instances were we hardcode the default duration (either 500ms for easeTo, 1000ms for resetNorth, and duration based on fly length in flyTo) — we should set those to 0 if window.matchMedia('(prefers-reduced-motion)').matches === false.

Not sure about fadeDuration — @CharlesBelov is this considered motion too? Labels appearing/disappearing abruptly might look worse for people sensitive to this...

[CharlesBelov]

I believe fadeDuration is as separate issue. For me, personally, the abrupt appearing/disappearing is usually problematic when triggered accidentally without intent, as in cursoring over something while on the way to something else or overshooting my target; it's best if there is a delay until intent is established (again, outside the current issue). That said, I'm not aware of major discussions on fading or not fading in association with prefers-reduced-motion; though it has come up from time to time.

[1ec5]

Fixed in #8494. mapbox/mapbox-gl-native#15187 tracks implementing the same feature on iOS.