View-Transitions: Respect prefers-reduced-motion

[mediaformat]

Bug Description

The view-transition plugin does not currently respect user prefers-reduced-motion, a device accessibility setting which helps with vestibular disorders.
See: https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html

Steps to reproduce

1. Go to Device settings
2. Enable Reduced Motion setting.
3. Browse site with any Transition Animation setting
4. See animations

Screenshots

Screen.Recording.2025-06-25.at.1.32.21.PM.mov

Additional Context

• Plugin Version: 1.0.1

[felixarntz]

Per my comment on the pull request, this is certainly a valid issue, but I think it needs some thought on what is the right way to address it.

A few questions I have I would like to see answered, ideally with accessibility experts weighing in:

• Should prefers-reduced-motion bypass every kind of view transition, regardless of how disruptive the animation is? Or are certain animations (e.g. like the default fade) okay to keep while others (e.g. where elements are moving) aren't?
• How do native mobile apps handle this preference? These apps pretty much always use smooth transitions (and have been for more than a decade), so it would be useful to look at the a11y best practices there to inform our approach for the web-based equivalent of smooth transitions.
• A more technical question: Is wrapping prefers-reduced-motion around only the @view-transition { navigation: auto; } bit sufficient to apply the bypassing? Or do additional view transition related CSS rules (e.g. those of the specific animations) also need to be wrapped with it?

Pinging @joedolson @amberhinds, as it would be great to get your insights here.

[joedolson]

The main factors that impact how important an animation is for accessibility are time, scale of difference, size of animation, and motion. With a full website, there is always a significant possibility that a view transition will operate at a large size, since it'll potentially be the entire monitor.

The specific type of animation does matter, because motion is a huge factor that doesn't really happen in a fade animation.

However, I don't think it's very feasible to determine which animations are acceptable and which aren't outside of specific examples. I'm not sure how the plugin would know whether a given usage was OK or not.

At level A, the only requirement is that an animation can't violate the three flash, general flash, or red flash thresholds. These are very specific, and relatively unlikely to be triggered by a view transition. That said, it would definitely be possible.

Many motion reducing settings are described as "reduce motion" settings, so it is understood that they won't disable all animations; it's just expected to reduce the amount of animation you're exposed to.

It should always disable looping animations or especially problematic effects like parallax, but transitions are definitely more subtle. That said, the controls for reducing animations are not very fine-grained, and this is a problem for users: as web developers, we have no way of knowing what specific types of animations or severity of animations might cause a user problems. Because of that, in my opinion, we should always respect prefers reduced motion for any visitor. This will only impact people who have already stated a preference for less animation, so I don't see any sound reason to leave this enabled just because they seem subtle from the view point of somebody who does not have an issue with animation.

The CSS Working Group's most recent official stance is that prefers-reduced-motion will automatically fall back to a cross-fade animation with no size or position animations. I don't know the status of implementation of that, however.

By intent, that seems to mean that view transitions should be automatically handled when prefers-reduced-motion is set; but I think that would merit some testing to verify what actually happens.

[amberhinds]

I was coming here to say this:

Many motion reducing settings are described as "reduce motion" settings, so it is understood that they won't disable all animations; it's just expected to reduce the amount of animation you're exposed to.

However, if we're just talking about the animation shown in the video, my inclination would be to remove the animation completely rather than change it to something more subtle, like a cross-fade. Users wouldn't expect a transition between pages to be animated at all, and if a site own added other auto-playing elements that also don't respect prefers-reduced-motion, then there could still be issues when the page transition combines with other animation. Removing it completely seems "safest."

[mediaformat]

Thanks @joedolson, @amberhinds for your input.

@felixarntz to respond to your questions

• Is wrapping prefers-reduced-motion around only the @view-transition { navigation: auto; } bit sufficient to apply the bypassing?

I tested with the default configurations (selectors), and the current PR effectively disables all view-transition animations with prefers-reduced-motion

• Should prefers-reduced-motion bypass every kind of view transition, regardless of how disruptive the animation is? Or are certain animations (e.g. like the default fade) okay to keep while others (e.g. where elements are moving) aren't?

I did consider whether a fade is a subtle enough transition, but ultimately decided on the simplest global on/off default. I am open to keeping the fade, but if transition duration becomes a user configurable setting, this might be inadvisable. #2040

• How do native mobile apps handle this preference? These apps pretty much always use smooth transitions (and have been for more than a decade), so it would be useful to look at the a11y best practices there to inform our approach for the web-based equivalent of smooth transitions.

The same OS level setting exists in iOS, and removes side-swiping effects in native apps. From some quick testing, in certain cases a swipe translated to a fade.

[felixarntz]

Thank you all for your insights.

Based on your feedback, I'm thinking:

• Any transitions that involve motion should not be possible with prefers-reduced-motion.
• To handle that, we can do one of the following:
  • Either require every registered animation to set a flag on whether it involves motion or not. In theory, probably ideal, but in practice, it requires every developer to know about it and use it responsibly, which unfortunately may not lead to the desired accessibility outcomes.
  • Only allow the native fade animation transition. Based on the CSS WG discussion and how native apps handle it, this seems most sensible.
  • Or disable all view transitions. This approach seems excessive to me. After all, a smooth transition, as long as it's without motion, actually avoids the "flicker" you'd get from a full page reload. If view transitions as a concept were having adverse effects on accessibility, I'd question why native apps use them. A smooth fade transition seems to be the norm for accessible native apps, so I think the web should embrace it too.

So my technical suggestion would be:

• Leave the default fade view transition as is.
• If any view transition animation other than the default is active, wrap its CSS code so that it only applies to users without prefers-reduced-motion.
• Similarly, for the control over the transition duration (see Allow control over view transition animation duration #2040), that CSS should only be applied to users without prefers-reduced-motion too.

Let me know if that sounds reasonable.

[joedolson]

That sounds like a good solution to me.