As per summary.

The only transition that's not in a media query is now https://searchfox.org/mozilla-central/rev/501eb4718d73870892d28f31a99b46f4783efaa0/toolkit/themes/shared/aboutReader.css#87-90 ; the other ones are all in a media query already after bug 1637652 and bug 1550836.

I'm not sure if reduced-motion should cover colour/opacity transitions, as objects aren't actually moving in that case. Dão, do you know?

(In reply to :Gijs (he/him) from comment #1)

I'm not sure if reduced-motion should cover colour/opacity transitions, as objects aren't actually moving in that case. Dão, do you know?

I'm not sure. If I had to guess I would say it doesn't need to cover it. Asa, do you know?

I couldn't find any specific guidance online about opacity transitions but I think we should have a generous interpretation of prefers-reduced-motion to mean the user prefers not to see any animations (key-framey like things) whether moving or not.

From MDN: "The prefers-reduced-motion CSS media feature is used to detect if the user has requested that the system minimize the amount of animation or motion it uses."

More:

https://webkit.org/blog/7551/responsive-design-for-motion/

"Even if your site uses motion in a purely decorative sense, only remove the animations you know to be vestibular triggers. Unless a specific animation is likely to cause a problem, removing it prematurely only succeeds in making your site unnecessarily boring."

and from a conversation I just had on an a11y slack with the author of that article and implementer on iOS (I think the first to support PRM):

PRM is to avoid triggers for vestibular motion sensitivity. Don’t remove your dissolve transitions.
It is not synonymous with “stop all animation” since animations like dissolves are not known to be problematic for those with vestibular motion disorders.
Animation can improve the usability of some interfaces. As long as they aren’t one of the known vestibular triggers, leave them when PRM is enabled.

So we do not have to curb dissolve transitions.

Just a note that it would appear a reply to the discussion here got posted to the metabug, bug 1478597 comment 17.

Can we close this then?

(In reply to Dão Gottwald [::dao] from comment #8)

Can we close this then?

Sorry, I think I forgot about the narrate highlight transitions, cf. https://searchfox.org/mozilla-central/rev/35b97af64a55d1d30caa4d6e9fabc1a7fbabc509/toolkit/themes/shared/narrate.css#34 .

I don't know how much of that we should even keep if the user prefers no motion - perhaps only paragraph highlights, but not word highlights? I would expect a non-transitioned word highlighting to be a pretty crummy experience.

I also believe there is some JS involved that expects these transitions, so it may not be as simple as just adding some media queries.

The severity field for this bug is set to S3. However, the accessibility severity is higher, [access-s2].
:Gijs, could you consider increasing the severity?

For more information, please visit auto_nag documentation.

My read on this is that the animations that are still enabled, which are the paragraph highlight and the word highlight moving to the item currently being narrated, should not be vestibular triggers according to comment 5? They're both quite subtle, and they both involve a single element moving in a smooth and predictable way in a single direction at a time. If I'm right about that, then we should close this bug.

Asa, does that seem right to you, or do you think there's still work to do here?

They are likely not common vestibular triggers but there are some people for whom just about any motion can be problematic. We don't have a policy that draws a clear line here though and we have at least one regular Bugzilla reporter who seems to be triggered by far more than what I expect is typical among users with the most common motion sensitivities. We've "fixed" several high-value, likely to not trigger many people, animations in the product already as a result. (Not 100% on the motivation, but see the tab spinner, for example.) IMO, we've probably gone too far on some of these resulting in diminished UX where we did not have to. That being said, I'd rather we caution on the side of protection (I certaintly don't want our products to cause anyone physical pain) over expression and so when we get user reports that aren't difficult to put behind the pref, I bias in that direction. I'm not sure whether this report from Gijs was the result of user feedback or not but if it was not, perhaps we can close this out. If on the other hand, we know that these specific minor animations are causing any users real discomfort, then we could consider putting them behind the pref. At some point though, we may want to consider two settings -- one that's baseline prefers reduced motion and doesn't disable things that aren't known and common triggers and second Firefox-specific setting that tries to suppress all motion for those few not covered by the more general setting. This could let those who are motion sensitive experience a potentially more rewarding product while also providing protection for those who are extremely sensitive.

Aaaaah I see; I should have realized this would be something that varies by individual. Thank you for the information.

Gijs, can you answer Asa's question about whether we had reports of issues here? I'm inclined to follow his suggestion of using that answer to determine this bug's disposition.

Honestly I don't recall exactly. When this got filed I would have been reviewing this patch where around the same time I asked for a transform transition in the redesign (which had controls at the top and was changed again shortly afterwards) to be behind a reduced motion media query to avoid similar issues. So it was clearly on my mind. I just can't see an obvious reason why, not even when looking at my bugzilla activity or incoming bugmail around the time.

Okay, thank you.

I think what I'll do then is close this bug for now. If this does end up being a problem for anyone though, please do let us know (either by commenting here, or privately) and we'll get this reopened.