When animation is an accessibility problem | Hacker News Reader

When animation is an accessibility problem

theverge.com

56 pointsTomte20 comments

I get very distracted by continuous animation on a page/app that I'm trying to interact with, to the point of just having to abandon meme-heavy articles or posts if every chunk of content is bookended by great flashy looping gifs or similar internet spew.

Even technical or otherwise useful animated gifs showing the evolution of some system or progression through states or whatever, can be both helpful and absolutely obnoxious if it's autoloop forever with no control.

SuperStop for firefox used to at least allow the halting of gif animation in a heavy-handed nuclear option sort of way, as does uBlock 'element zapper' tools, but if the content isn't immediately good enough to warrant those sorts of readability interventions, I'll probably just bounce.

Electron and other native apps are even worse - good luck if you want a more nuanced control of your animation (including things like animated emoji/stickers/whathaveyou) than LOOP FOREVER or OFF.

IMO, just another reason that things like chat services (Slack, say) that force you via TOS to not make your client usage experience less uncomfortable are a blight on the modern computing ecosystem.

Hey web developers, do you know about the CSS "prefers reduced motion" media query that allows you to make your site/app more accessible to people like shabble?

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

https://caniuse.com/?search=prefers-reduced-motion

At least CSS animation is optional. I have the following in chrome/userContent.css in my Firefox profile directory:

  @namespace url(http://www.w3.org/1999/xhtml);
  
  *, :before, :after {
  transition: none !important;
  animation-delay: 0ms !important;
  animation-duration: 0ms !important;
  }

This also requires setting toolkit.legacyUserProfileCustomizations.stylesheets to true in about:config

As far as I can tell this doesn't break anything important. I also have the same in chrome/userChrome.css (without the namespace header), which occasionally breaks the tab bar in what looks like a race condition bug, but it's still worth it IMO.

Kudos, i'm borrowing this one.

I could see this maybe breaking assumptions in an onTransitionEnd callback, but if it's mostly working for you then good for you :)

We are a very diverse bunch - some people like endless emoji animations some hate them. How would we implement a web that works well for (almost) everyone? Something like an alt_videoframe=3 that is static when the user chooses so? What about fade-in / slide transition vs. instantly displaying hidden text after clicking "show more"?

I feel like the whole accessibility discussion is not visible enough. So many websites presume specific display settings and perfect vision among its users. Even the initial caps in the linked article are overdone in my opinion - think about non-native English speakers and how they may be very confused by them.

edit: a good example can be the newly rolled out Reddit feature: "Shop Avatars" - they added a constant animation on the top which is really annoying.

People can't look beyond the specific use case they envision. For example, probably half the pages linked on HN are just godawful to use on a mobile browser in landscape mode.

That's a good point and highlights how important it is to make software widely accessible.

Reminds me of device driver problems on Linux and the "works for me" mentality. When you take into account various types of devices, resolutions, operating systems, use cases, language barriers, user age, vision problems and disabilities the number of possible issues is staggering. I think a well engineered product should never be ignorant of them and cover as much as it can (as long as it's feasible).

Just like OS dark mode settings, have a toggle for animations too.

Then let the developers and designers use the switch if they care.

> Just like OS dark mode settings, have a toggle for animations too.

Happily, this exists! My other response links to more detail on the CSS "prefers reduced motion" media query, including where to find this toggle on various OSs.

Web animations should be inside

  @media (prefers-reduced-motion: no-preference) {

  }

Unfortunately, enabling the reduced motion preference leaves you vulnerable to fingerprinting even with Javascript disabled. See:

https://news.ycombinator.com/item?id=30237846

And reduced motion is still motion. I prefer disabling all CSS animations (see https://news.ycombinator.com/item?id=32094641).

Though we still owe it to users to respect that preference if they have set it.

Most of the time this is a good default approach. But sometimes animation can help to improve accessibility (e.g. when motion or a brief change in emphasis helps convey a state change that may be less noticeable without it). This is where reduced is an important distinction. For cases where animation is helpful but the user prefers reduced motion, the animation’s duration can be reduced and/or the animated property changes can be subtler.

Can I frame my aversion to pop-over windows as an accessibility problem? Can I sue the E.U. for cookie banners being an accessibility problem?

No, the EU is not mandating cookie banners. That is just the web industry trying to get around the laws prohibiting them to store random cookies, especially tracking ones, without consent.

The first thing I do on an Android phone is to disable animations. Unfortunately it makes some apps to do funny things (broken progressbars), and some animations will play anyway (opening apps from home screen)

Animation is often cool: The first time I use it.

After that, it becomes quite tiresome.

I tend to use animations in my work, but only as half-second fade transitions, and whatnot. Makes the user experience smoother, and doesn't result in "twitchy screen fatigue."

It's also not so simple to implement, by hand. Many frameworks have them embedded, so you get them for free, but I write native, so I often need to construct them, manually.

Thankfully, there's always a way to discard an offending node in the DOM, but really, why do I have to do this every time, I want to read an article? (I'm speaking of you, Ars Technica, but – sadly – not exclusively.)

Rule of thumb: any permanent element should be also (visually) static.

Even the new static doodles that windows has added to the search box are too distracting for me.

I have ADHD and I'm just trying to get my work done, and even my OS is trying to take advantage of me when I'm not at my best to maximize some attention-capture KPI.

Reply on news.ycombinator.com