In our accessibility documents we currently state: "Firefox does not use animation in its user interface. Additional related features: Firefox can be configured to turn off animation in images used in web content via the about:config setting called "image.animation_mode"" http://www.mozilla.com/en-US/firefox/vpat-3.html The initial statement is no longer true with the Firefox 4 UI, as we've been introducing animation for loading progress bars, opening and closing tabs, and a number of other things like zoom effects in panorama. To continue to comply with this section, it looks like we need to add a checkbox to Options > Advanced > General > Accessibility to allow users to disable our UI animation. This option would likely be used by users effected by photosensitive epilepsy or migraines.

I'm tentatively requesting blocking since this may be a compliance issue. Alternatively we might just need to update our Voluntary Product Accessibility Template until we can address the issue, if anyone can clarify that would be helpful.

Related to bug 161109?

davidb, can you comment? What's the motive for disabling animations? To make items visible with magnification tools and such? Does that really apply to "trivial" animations such as tab-closing?

As I understand it, and as Faaborg mentioned, it can be a concern for users who can suffer from epilepsy, and also perhaps users with cognitive issues. This is the relevant section: http://www.uspto.gov/web/offices/cio/s508/02software.htm#standard_h The image.animation_mode setting was only for animated images I think. The suggested method for measuring compliance: "To determine the full set of controls that display animation, methods include: Observation of the product interface Review of the product documentation (e.g., user manuals and online help) The software must provide each animation's content using an alternate means. For example, for each informative animation sequence, a text or audio equivalent may be provided." Tab-closing info is implicit, but I do think we should consider progress and throbbers. Alex F, are you going through the VPAT for FF4?

>Alex F, are you going through the VPAT for FF4? no, someone else on bugzilla mentioned this specific discrepancy so I wanted to get a bug filed so we didn't forget to address it. >As I understand it, and as Faaborg mentioned, it can be a concern for users who >can suffer from epilepsy, and also perhaps users with cognitive issues. My understanding is that sometimes even slight animations can cause motion sickness and headaches for users with certain conditions, although I unfortunately don't know much more than that. Most of our animations (with perhaps the exception of the tab zoom in panorama) aren't likely to be significant enough for the full epilepsy concerns, but they may cause a segment of the population to experience discomfort.

(In reply to comment #6) > My understanding is that sometimes even slight animations can cause motion > sickness and headaches for users with certain conditions, although I > unfortunately don't know much more than that. Most of our animations (with > perhaps the exception of the tab zoom in panorama) aren't likely to be > significant enough for the full epilepsy concerns, but they may cause a segment > of the population to experience discomfort. The animations that are currently used can't be any worse then watching a page load, even on a fast connection.

>The animations that are currently used can't be any worse then watching a page >load, even on a fast connection. yeah, or scrolling. From some brief in person conversations with users at a conference about disability access, I think an option like the ability to disable UI animation would be combined together with a lot of other preferences as well. For instance turning off images entirely, turning on high contrast mode, and only using the space bar (with smooth scrolling turned off) to scroll pages. These users also are big fans of ad blocking software. Trying to experience the Web without a lot of constant visual change is a pretty difficult challenge, but nonetheless it is my understanding that some users would nonetheless take advantage of the ability to disable UI animation. They would probably also like the ability to force Firefox to only do a single reflow when loading a page (I'm not sure to what extent we can easily control that right now though).

if you marked bug #466286 a duplicate then you should also merge #456620 and #422260, too

Cc'ing Jeff and Joe for comments on implementation.

(In reply to comment #0) > The initial statement is no longer true with the Firefox 4 UI Hasn't Firefox had an animated throbber since before it was called Firefox?

FYI: if it would help, we in Panorama would be happy to check for some pref value and disable animations across the board based on it, though it may not make it in time for fx4 if not made a blocker.

Ctrl+F is now also animated.

Animations might be fun (for some) to look at once, or twice, or even tens of times, but as soon as someone is really using a software, they are a huge waste of time. One might wait minutes in a single day. So while they do not provide any real value, they can at least affect the economy. Really, is there a general public request for all of these animations? (including the animations in macOS, Windows, etc.) Or most users are simply too uneducated (in computers) just to imagine the devs should provide them an easy option to get rid of all of these useless animations. Right now Windows is more user friendly from this point of view. The default value for this property should be autodetected from the settings of the operating system.

See also: bug 1352069

(In reply to LC from comment #14) > Animations might be fun (for some) to look at once, or twice, or even tens > of times, but as soon as someone is really using a software, they are a huge > waste of time. One might wait minutes in a single day. So while they do not > provide any real value, they can at least affect the economy. Part of the work we are doing for 57 (Photon) is to revise many of the UI animations so they are faster and serve to ease a transition rather than add flair. They shouldn't slow down any interactions with the browser, and are there to mitigate the jarring effect of something just appearing/changing in place - which never happens in the real world. Other animations are to subtly draw attention to a change - like for example the tab is loading content, or a download has finished. Bug 1352069 consolidated a lot of the UI animations under one pref. And bug 1357349 covers exposing that to the user in the preferences UI. I think that will cover the requests being made here so I'll dupe to that. If there are more animations which should be toggled by this pref, lets file separate bugs for them.

I noticed the work of #1352069 in FF 55, and I'm happy about the progression of this and related bug reports (and I might add: finally!). I'm just adding a comment here however to point out that while transitions might help to ease unexpected transitions, and are occasionally useful for orientation, they are hardly harmless in terms of effective and perceived UI lag. For instance, an UI transition should never block UI state. If a shortcut is pressed while an animation is active, the animation /should/ be cancelled. By first hand experience, proper chaining of animations in an UI so that state is never blocked or visually corrupted is hard. Secondly, transitions are experienced as visual lag not only by experienced people, but also by relatively novice users. That is, once you know a window is going to appear, any delay is perceived as lag. Switching off transitions in windows is often seen by inexperienced people as a massive performance boost in my experience, even though their user interaction (by mouse) does not actually introduce any slowdown/harm for them. Sadly, novices are also people that are often "sold" to animations to begin with. Transitions and animations in UIs are useful, sometimes important, but in a _very_ narrow set of cases.

(In reply to Sam Foster [:sfoster] from comment #16) > They shouldn't slow down any interactions with the browser, and are > there to mitigate the jarring effect of something just appearing/changing in > place - which never happens in the real world. Other animations are to > subtly draw attention to a change - like for example the tab is loading > content, or a download has finished. Whether there are instant appearances/changes in the real world or not it's more a philosophical question (but quantum physics also disagrees with you) than some kind of strict rule that should limit our possibilities. E.g. a combobox is not a sheet of paper, the items are not "behind" the textbox, animating the appearance of the items is a mere illusion for one's satisfaction (and for annoying others). The same applies for every dialog, popup, etc. On the other hand I never heard anyone complaining about the letters just appearing as a whole during typing, while handwriting is pretty slow and you can definitely see how each letter is formed. So I still prefer not being forced to think and believe as others say (and I assume I'm not the only one), that's why I don't really understand arguing against the ability to (completely) switch off the animations. What is the planned/approximate release date of version 57 (Photon)?

(In reply to LC from comment #18) > So I still prefer not being forced to think and believe as others say (and I > assume I'm not the only one), that's why I don't really understand arguing > against the ability to (completely) switch off the animations. I think we agree. This is exactly the reason why we are gathering these animations under a single preference and exposing them for users to easily disable in bug 1357349. > What is the planned/approximate release date of version 57 (Photon)? https://wiki.mozilla.org/RapidRelease/Calendar shows merge day this week (nightly will become will be be 57) and releases 2017-11-14 .