search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
160.4k stars 28.1k forks source link

Pause animated gifs in extension readmes #134514

Closed WilcoFiers closed 1 year ago

WilcoFiers commented 2 years ago

Apologies for opening this after #119785 was closed, but I feel common accessibility issues like this should not be ignored.

Open the extensions panel

  1. Search for comment-autocomplete (or any number of other extensions with animated gifs)
  2. Does this issue occur when all extensions are disabled?: Yes

It is fairly common place for extensions to include animated gifs in their readme. These then show up on the marketplace page on visualstudio.com, as well as in VSCode itself. Animated gifs can be fairly distracting for people with certain cognitive disabilities such as autism. For quite a few people, animations are so distracting, it is essentially impossible for them to read the text. This is captured in the pause, stop, hide requirement of Web Content Accessibility Guidelines.

One way this could be addressed is for VSC to wrap each animated gif in a little widget that adds a small pause / play toggle button in the bottom right (or left for RTL languages). There are some tools to do this out there, such as freezeframe.js The best solution would be only to animate when the user hovers / activates the image. Make sure to make the mechanism to start/pause keyboard accessible.

joelanman commented 2 years ago

another approach could be the one Slack uses, to have a preference in the app to turn animations on and off

sinabahram commented 2 years ago

Just want to echo/amplify three salient points here.

  1. There absolutely needs to be an exception for accessibility issues being closed. This is a matter of basic equity, and a clear situation where an automated solution is disproportionately harmful for persons with disabilities and those who use assistive technologies. It's understandable as a mechanism for controlling issue counts, but a clear exception around a11y issues must be made immediately. This is an easy actionable thing that can be done. So, I hope that doesn't get lost within the details of this important issue.
  2. I agree with the suggestion of customizability and preferences. Browsers have "Reduce Motion" settings, and many blind folks actually use that setting too, not just folks with vestibular and related issues, because these animations can cause needless delay all over the interface (less so with animated gifs and far more so with other forms of render animations, but still). Low vision folks also benefit from this because of needless animations happening during magnification.
  3. I would advocate for a single control instead of individual play/pause controls so as to keep the interface clean for everyone. This is related to having a global setting as well. I love the idea of only animating on hover, too, but that behavior should still respect "Reduce Motion" and/or another global customization to turn off animations.

Props and gratitude to @WilcoFiers for persisting with this issue. It is meaningful and important.

jeherringer commented 2 years ago

I think having a global preference setting makes a lot of sense for a situation like this, and I generally personally prefer having control over global settings than a "per element" basis so to speak.

That said, regardless of implementation this absolutely is something that should be implemented and as @sinabahram stated, it is important that these animating elements respect "reduce motion" and similar controls from the users end.

vavroom commented 2 years ago

It isn't just an issue around distractability - animations can make people sick. My wife spent 2 days in bed last week with a bad migraine caused by unexpected animations.

mikemai2awesome commented 2 years ago

I am sorry, but this baffles me. It is such a basic thing to take care of, why does Microsoft need anyone to open an issue about this? Their accessibility team should have taken care of this in the first place.

jlk4p commented 2 years ago

This is problematic for me. I use VS Code. Animated Gifs prevent me from focusing on content and cause headaches. I also use Slack which allows animated Gifs - but they allow me to disable animated Gifs via my preferences. VS Code should at minimum offer the same ability to disable animated Gifs.

elearningDev commented 2 years ago

Here to support this requested change!

P.S. For those who haven't created a new github account recently, let me tell you, the "welcome" screen upon initial sign-up is anything but. It's a zooming star field with some other high-speed animated monkey business. I don't have vestibular issues, but I got queasy and disoriented with that unexpected full screen in-my-face animated extravaganza. Oof.

Lemmingh commented 2 years ago

wrap each animated GIF in a little widget

AFAIK, this means taking snapshot of the original image on the fly and covering it (<img>) with the snapshot (usually <canvas> or <img>) on demand. The freezeframe mentioned above takes this approach.

Other solutions I know might not be suitable for VS Code: Transcoding the original image to other formats and playing back it via <canvas> or <video>.

APNG and WebP should be also considered in addition to GIF.

KristinaEngland commented 2 years ago

I echo what everyone else has said. It needs to respect reduced motion settings. As someone with a vestibular disorder, I need the ability to shut off animations entirely so that my vertigo isn't triggered by them.

ElleWaters commented 2 years ago

Adding my support for this specific ticket raised by @WilcoFiers and for @sinabahram 's comment about providing an exception to all accessibility issues so that it doesn't get caught in the default-close behaviour. Not all bugs have the same impact on end users, and we're smart enough to have equity-based prioritization.

andrewmcdonald-oxb commented 2 years ago

Would just like to add my support for this. I've just had to resize my VS Code window after updating to 1.63 because of the animated gif of previewing themes through the marketplace. Resizing to get this image off the bottom of the window was the only way I could concentrate on reading the intro text. This animation was particularly problematic because it flicks between so many different colours in a large image.

You could display a playing/paused symbol faded over the top corner of such gifs when the user mouses over. Personally I'd probably not disable playback by default, but it'd be a huge improvement over my current experience in certain situations. I'd even like to see it go further, with a draggable timeline slider appearing on mouse over so I could slide through such animations at my own pace. I usually find I have to watch the release notes ones dozens of times over before I understand what's going on, because I'm not in control of the animated mouse cursor and can't even tell where the beginning and end of the animation are.

oliversalzburg commented 2 years ago

Just wanted to note that the recently added "Reduced Motion Mode" has no effect on this behavior. Seems a like a missed opportunity :(

lupinia commented 2 years ago

Echoing the sentiments of others here: I find it frustratingly ironic and extremely disappointing that, after updating, I was struggling to read the release notes announcing the new Reduced Motion setting, because the release notes were completely full of animated gifs that could not be stopped and kept on playing after I enabled Reduced Motion. This is almost worse than not having a Reduced Motion feature at all.

sinabahram commented 2 years ago

Commenting to amplify the experience of others.

I'm hoping this update can either be revisited or its remediation per the above feedback prioritized. I find the point made by @lupinia to pretty much sum it all up.

In my constant effort to improve systems, not just fix bugs, I very much hope that A) my 3 points outlined above are being taken into consideration, and B) that the fact that this accessibility fix/feature was launched in such a way that unintentionally caused some of the very issues intended to be fixed is treated as a learning opportunity, hopefully resulting in some additional measures being taken to verify the design intent and post-implementation checks (or lack there in) in any testing protocols being used before launching to prod.

Thank you everyone for what you are doing to make things more inclusive each day.

Lemmingh commented 2 years ago

Reduce Motion is evidently off-topic here. I don't understand why you people talk about it.

"Reduce Motion" (#128595) is "Limit animations used in the VS Code UI". Its release note and Setting ID clearly say "workbench".

"Pause GIF" is "Control the media playback for images in the webview". The Release Notes and READMEs are rendered by webview.

CSS animation and media playback are totally different areas.

VS Code cannot decode videos, thus, <video> is impossible, and it's actually not a good idea to transcode a GIF to some video stream. <canvas> is the only choice to build a player.

Anyway, I took a look at the GIF89a spec and relevant material a few months ago, finding that rendering is a big challenge. Others, such as decoding, memory pressure, and DOM manipulation, are also important but not so serious.

The animation in GIF is defined by "delay" (Graphic Control Extension), which is much different from straightforward concepts like "rate", causing the playback is indeed platform-dependent. In other words, animation is achieved by repeating "draw a sub-image and wait for a delay", thus natively, the same GIF can be fast on one device and slow on another.

There are two interesting decoders: omggif and gif-viewer. omggif is well-known, but the community-managed type definitions are partly wrong, and you need to learn the real shapes from its source code. gif-viewer is immature with lots of debug statements, and you need to clean up all the mess before using it.

Additionally, it's possible to take advantage of WASM-based things (gifcap), but I'm not really familiar with that and didn't try.

I failed to build a player based on above knowledge. The outcome was horrible. When a small delay time exists, the playback speed goes out of control.

Chromium appears to manage to play GIFs steadily by seemingly having a minimum allowable delay, but I'm not sure. I am curious about and have no idea of how it works.

Let's see how the VS Code team will evaluate the problem.

lupinia commented 2 years ago

@Lemmingh You are correct that, from a purely technical standpoint, these issues are unrelated. And you make some excellent points; you clearly have a deep understanding of the technical considerations needed to resolve this. However, it's worth considering that accessibility issues are primarily human issues, and human issues don't always map cleanly onto technical issues or technical solutions. So that's why people are relating this animated gif issue to the newly-released reduce motion setting: They may be distinct technical issues, but they are the same human issue that logically have the same solution: It's a reasonable assumption that someone who needs to enable Reduced Motion for the UI will also need to disable animated gif autoplay, because the underlying problem they're trying to solve is to reduce the amount of movement on their screen. And while it's also reasonable (and probably necessary) to accomplish this by having two separate settings to toggle (one for UI motion, one for animated gifs), it's a grave and concerning oversight to only implement one half of that equation.

tl;dr: I agree with your technical assessment, and I appreciate your expertise and insight, but the reason we're invoking/referencing the Reduced Motion setting isn't because they're the same technical solution, it's because they're both causing the same human problem, and the animated gif side of the solution to that problem seems to have been ignored. The fundamental problem we want solved is for this oversight to be corrected, and I don't think anyone particularly cares how it gets done :)

oliversalzburg commented 2 years ago

Just for context, other tickets about animated GIF usage in VS Code have been pointed here and previous comments suggested the problem should be solved in all areas by the introduction of the reduced motion mode. The fact that these two things now have nothing to do with each other is unfortunate. The fact that there was a reduced motion mode introduced that simply does nothing in regards to very distracting animations in READMEs is also unfortunate. The fact that there are no good solutions for playing back animated GIFs should be an indicator that they are completely misplaced in the product here.

gjsjohnmurray commented 2 years ago

Related upstream request https://bugs.webkit.org/show_bug.cgi?id=23945

gjsjohnmurray commented 2 years ago

Is there any way this trick could be used?

https://css-tricks.com/gifs-and-prefers-reduced-motion/

Lemmingh commented 2 years ago

GitHub released a new accessibility feature called "Autoplay animated images", which respects OS reduce motion settings, of course.

They take the simplest approach "covering with a snapshot" (Not a real player). The snapshot is produced by just drawing the image in a canvas:

canvasElement.getContext('2d')!.drawImage(img, 0, 0, img.offsetWidth, img.offsetHeight)

Given that GitHub implements the feature with only ~200 lines of TypeScript code, perhaps VS Code could also start here, as the opening suggests, and introduce a fine real player gradually.

Note that the prefers-reduced-motion CSS media feature reflects OS reduce motion settings, while VS Code's Reduce Motion is now indicated by the reduce-motion CSS class (4ef11afa305accdc718965cc4fe809e77ff8040d). There might be some tricky things.

mjbvz commented 1 year ago

As we now support mp4s, I'm going to investigate enabling videos on extension pages. A few points about this:

mjbvz commented 1 year ago

In the latest VS Code insiders, <video> tags should now work on extension readme pages and on marketplace on web. Please give it a try in the latest insiders builds and file new issues for anything that doesn't work as expected

A few important notes about video support:

I know this doesn't help with existing readmes that contain gifs, but after weighing the cost of implementing and maintaining pausable gifs, and after considering all the ways in which video files are superior to gifs, I decided that we want to focus on video support instead. If you own an extension that uses gifs in its readme, please consider switching it use use videos instead (and also help file friendly bugs/PRs against extensions that you wish had pausable content in their readmes)