Public Comment on 2.3.3 Animation from Interactions and prefers-reduced-motion

[CharlesBelov]

Since WCAG 2.1 was finalized, a new technology has emerged in which some operating systems expose to user agents, and user agents in turn expose to content models, that the user has requested animation be "reduced" (Mac, iOS wording) or eliminated (Windows).

My comment is that if a user has requested this reduction/elimination and the user agent exposes that information to the content, respecting that request by not doing any animation from interaction would appropriately be AA.

As I recall, the concern with making item 2.3.3 be AA with WCAG 2.1 was that there was insufficient study to decide whether a particular animation is problematic. I believe that the user telling their OS that animated content is problematic is sufficient to determine that it is unnecessary to make the problematic-or-not determination, and just eliminate all non-essential animation in such cases.

This is already an emerging best practice and would best be formalized as part of WCAG 2.2.

If an operating system or user agent does not pass this information through to the content, the AAA specification would remain as it is in WCAG 2.1.

[mgifford]

That is a solid recommendation. VIMS is a serious issue that is barely addressed by sites. I think this would do a lot to make animations an issue that people actually pay attention to.

[patrickhlauke]

I believe that the user telling their OS that animated content is problematic is sufficient to determine that it is unnecessary to make the problematic-or-not determination, and just eliminate all non-essential animation in such cases

debatable...as users are only given a binary option, and are usually only affected by very specific/drastic types of animation, this is a big hammer that would immediately disallow any, even the most subtle, of changes in opacity, subtle 1px movements shift of something, etc. in theory, if you implied that, a page with a single dot somewhere that faded by a single color/luminosity/opacity value could be deemed to FAIL. of course that'd be unrealistic and silly. again, look at it in light of "would you think that a site can be sued if they do this?"

long story short, keep at AAA. propose a good technique that to pass the SC, sites can listen for / adapt to any preferences that may be exposed (because of course it IS the safest way to pass in that context, since you're basically not taking any chances as a developer). but of course, it's then a matter of determining if that is sufficiently "accessibility supported".

related #1074

[patrickhlauke]

also, let's be clear about the difference between what a normative SC requires, and what a sufficient technique's purpose is. saying "if a site did this, they'd be able to pass this even if it was AA" is of course true, but that's not how levels for SCs etc work. essentially you're arguing that the SC can be made AA if we say "sites should just not do any animations at all (if the user set prefers-reduced-motion)" which is a far too draconian take. sure, as a technique that's fine. but not as a normative SC, i'd say (and it would leave a gap for platforms/user agents/situations where users aren't able to express their preference...and you then can't say "oh but in that case it's a AAA requirement")

[mgifford]

Well, we could specify size & duration. I just think if it's just an aspirational SC then it's never going to spur any change in action. Yes, there may be some subjective elements (as there are in WCAG 2.0 specs too).

I wish there was some simple math equation that we could use. Hmm, ultimately it's size (mass) & velocity (change) over a length of time, right? So we could potentially come up with some rough number 20px² x 5px/s for 2s. Someone better must have already come up with some simple math that could be leveraged for this.

Big sustained moving blocks should be possible to block by the user. The challenge is to start with some parameter that is big enough so that everyone can agree.

[patrickhlauke]

we could potentially come up with some rough number 20px² x 5px/s for 2s

I can't wait for audits where we're ending up with screen rulers and calculators just to determine if something's a pass or a fail based on some arbitrary threshold... ;)

[mgifford]

Just to be clear contrast ratios of 4.5:1 for Level AA and 7:1 for Level AAA seem pretty arbitrary. I'm sure the same arguments were probably made back in 2007/2008 when WCAG 2.0 was being hashed out. But we found simple tools that made this much easier to evaluate. Now we don't think about it.

I'm pretty sure that similar tools could be built that evaluated animations to determine the quantity of movement in a page. But as with color contrast, until it's a requirement we're not going to see a lot of tools to help evaluate it. I'm definitely not seeing this as something that anyone will calculate by hand. We just need the right code.

[guyhickling]

I absolutely agree with Charles - if the user sets the prefers-reduced-motion setting, then the WCAG is honour bound to come up with an SC to protect that request.

Firstly though, I always think putting anything in AAA is pretty much a waste of time so far as most websites are concerned. Level AA has become so established as the norm that most IT teams won't consider anything at the higher level. Far too many IT teams only want WCAG compliance and are not actually overly concerned about helping disabled people. (As a side point, what we need is some better method than AAA for encouraging the take up of matters not required at Level AA.)

I think Mark has the right idea, "we could specify size & duration". To me, the most annoying animation effects are the ones that repeat over and over a number of times. I don't care what kind of effect it is, I just don't want it repeating many times. If something happens just once and doesn't repeat, I'm usually happy with that (well, I'm not if it happens all over the page, for instance a hover effect on every link, but I'm happy if it doesn't happen often. Maybe this brings a limit on the number of places on a web page where an effect is used, in addition to size and number).

The other thing I don't like are the massive explosions of something, covering half the page - where Mark's "size" would come in. But they aren't so common, so while size might be more difficult to put a limit to, maybe is isn't so critical (until designers decide it's the next new fad to go for!)

So if the user sets the prefers-reduced-motion, I would suggest allowing anything that happens once and doesn't repeat, and doesn't reverse (for instance not something that grow's in size then goes back to original size - that's repeating the change in reverse and is on the threshold of becoming annoying). That would allow most of Patrick's "subtle" changes, but stop the really annoying things that dance around for several seconds before subsiding.

We don't have to get all concerned about whether we are allowing too little. If the user has said they want reduced motion, lets give them that and err on the side of too little motion rather than too much. Or maybe give them no animation at all, which is maybe what many people who set it want anyway. When the user has stated a firm preference, let's not object.

[patrickhlauke]

for repeating things, arguably https://www.w3.org/TR/WCAG21/#pause-stop-hide applies to an extent?

We don't have to get all concerned about whether we are allowing too little

I do, as if we make things too restrictive, developers will simply start to ignore WCAG unless forced to adopt the SCs that appear too draconian, and it will likely make potential legal cases argue more around whether or not a failure due to a hardline interpretation of a too-draconian SC is having an actual detrimental effect on real users if a site ignores it.

The other thing I don't like

but is WCAG about what individual people "don't like" or what actually causes them tangible problems? I see a lot of proposed new SCs that try to outlaw "things I don't like" ...

When the user has stated a firm preference, let's not object.

The user has expressed a firm preference for reduced animations/motion. To infer from that that they want absolutely no animation is...a take, of course, but maybe not a correct one in all cases (as a random anecdote https://developer.paciellogroup.com/blog/2019/05/short-note-on-prefers-reduced-motion-and-puzzled-windows-users/)

[MikeElledge]

I think the challenge will be to find an evidence-based standard that has broad applicability. Does anyone from the cognitive team know of one?

I think the answer will be it depends on individual preferences. In which case, where would this fall?Within a website’s ability to adhere to web standards?

Mike

On Mar 8, 2020, at 4:03 PM, Guy Hickling notifications@github.com wrote:

 I absolutely agree with Charles - if the user sets the prefers-reduced-motion setting, then the WCAG is honour bound to come up with an SC to protect that request.

Firstly though, I always think putting anything in AAA is pretty much a waste of time so far as most websites are concerned. Level AA has become so established as the norm that most IT teams won't consider anything at the higher level. Far too many IT teams only want WCAG compliance and are not actually overly concerned about helping disabled people. (As a side point, what we need is some better method than AAA for encouraging the take up of matters not required at Level AA.)

I think Mark has the right idea, "we could specify size & duration". To me, the most annoying animation effects are the ones that repeat over and over a number of times. I don't care what kind of effect it is, I just don't want it repeating many times. If something happens just once and doesn't repeat, I'm usually happy with that (well, I'm not if it happens all over the page, for instance a hover effect on every link, but I'm happy if it doesn't happen often. Maybe this brings a limit on the number of places on a web page where an effect is used, in addition to size and number).

The other thing I don't like are the massive explosions of something, covering half the page - where Mark's "size" would come in. But they aren't so common, so while size might be more difficult to put a limit to, maybe is isn't so critical (until designers decide it's the next new fad to go for!)

So if the user sets the prefers-reduced-motion, I would suggest allowing anything that happens once and doesn't repeat, and doesn't reverse (for instance not something that grow's in size then goes back to original size - that's repeating the change in reverse and is on the threshold of becoming annoying). That would allow most of Patrick's "subtle" changes, but stop the really annoying things that dance around for several seconds before subsiding.

We don't have to get all concerned about whether we are allowing too little. If the user has said they want reduced motion, lets give them that and err on the side of too little motion rather than too much. Or maybe give them no animation at all, which is maybe what many people who set it want anyway. When the user has stated a firm preference, let's not object.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[guyhickling]

https://www.w3.org/TR/WCAG21/#pause-stop-hide applies to an extent?

No it doesn't, because that SC only requires that a button or similar means to stop the animation is provided. Or the animation can run for 5 seconds before it stops. But the user still has to get to the button - and for keyboard users, or for a mouse user who is immediately overcome by the effect of an animation and rendered unable to operate effectively as soon as they see it, that can take some time. And 5 seconds can be way too long for some motion sickness sufferers.

On websites it's done by a media query, so doesn't stop the developers doing whatever animation they want for most users. The developer adds a few lines of CSS in the media query to stop the animation, but it will only do that where the user has selected the no-animation setting. The user has control. Full details are at https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion

"The user has expressed a firm preference for reduced animations/motion. To infer from that that they want absolutely no animation..."

That's actually not the case. The user has selected whatever option their operating system or browser has given them to turn off or reduce or otherwise get rid of the traumatic effects animations may have on them. On Android phones its called "Remove animations", on iPhones its "Reduce motion", on my Windows 10 PC it's "Show animations" - which can be set to either on or off, no in-between.

But they all set prefers-reduced-motion. What happens after that depends on the developer. What the WCAG must do is to say, in an SC designed for this purpose, what the accessibility requirement must be to stop motion sensitive people being affected by animations they don't want. One writer on the subject described the internet, for people with motion sickness problems, as "walking a tightrope", always in danger of opening a page that will send them into immediate crisis. So we need to create an SC that will protect people.

is WCAG about what individual people "don't like"...?

I agree, bad choice of words on my part. It simply meant that what I, as a person in good health just don't like, people with certain disabilities may find incapacitating.

@CharlesBelov is quite right in highlighting it. We just need an SC to require developers to allow users to prevent animations happening, and it should be Level AA for the reasons he states. Operating systems and browsers have provided "prefers-reduced-motion" for the purpose, the WCAG just needs to ensure developers use it.

And the more I think about it, the more I think that, since some people can be seriously disturbed by animation of any kind, the answer is to require the animation to be stopped completely by the media query. Even a very limited animation can be too much for some people, and at least annoying for many others.

The developer still has the option, if they think the animation is important enough, to provide a button to start the animation if a user who has selected the setting chooses to (perhaps on a particular website where they know the particular animation is one they can cope with). But then the user can press the button when they are ready, not have the animation forced on them the moment the page loads. (The button will also only show if the media query has found that the non-animations setting is checked, so no disturbance to the design most people will see.)

[patrickhlauke]

No it doesn't, because that SC only requires that a button or similar means to stop the animation is provided

it says "there is a mechanism". this mechanism does not necessarily have to be a button, or something provided by the author if they rely on a standard feature of the platform itself (like taking a cue from prefers-reduced-motion).

What the WCAG must do is to say, in an SC designed for this purpose, what the accessibility requirement must be to stop motion sensitive people being affected by animations they don't want

A more generic SC that relates to honouring (to whichever extent) user preferences would be more apt in my mind. Couched in sufficiently subjective language for evaluation based on the specific context (rather than a blanket "stop everything/remove everything" draconian requirement. https://github.com/w3c/wcag/issues/1074#issuecomment-596087396

And the more I think about it, the more I think that, since some people can be seriously disturbed by animation of any kind

but that's the point, it's not "animation of any kind". It's specific magnitudes/types of animation. from the really problematic ones like parallax scrolling to the subtlest of "this color shifts by an almost imperceptible value over the course of 1 minute". Sure, demanding that simply nothing be animated is one way to be sure, but this lacks nuance and brings with it its own problems - for instance, about what specifically "animation" is - somebody overzealous, for instance, could start arguing that the very act of scrolling is "an animation" ... so you start contorting yourself in trying to find some pseudo-scientific pseudo-technical language to exempt some things.

(this all comes down to the fundamental conundrum of WCAG 1.x and 2.x - as it's a binary pass/fail assessment, it has the need to reduce "subjective" interpretation/definition, so it then tries to normatively define what is and isn't a pass or fail and set some arbitrary lines in the sand. but the real world is complex, and context matters. and the fact that WCAG is treated as a "law" essentially means that whatever decisions are made - even well meaningly - by the WG result in essentially saying "any site that doesn't do X can be sued".

[CharlesBelov]

It's not just about VIMS; it's also about hyper-vigilance and attention impairments. If my concentration is distracted by animation, even small-area, sub-second ones, then I have to spend additional time/mental energy re-acquiring my focus on the content; having merely the ability to stop the animation doesn't make up for the price of the interruption.

Some people on battery devices may disable animation to extend battery life, or to improve performance for power (as in expert) users. I admit to not being knowledgeable about this one, but I have seen it mentioned as being a thing.

The advantage of taking the Android/Windows interpretation (on/off) as opposed to the Mac interpretation ("reduce") is that you don't have to spend any development time determining what is just enough or too much animation. It's on or it's off.

The spec can state that unmoderated screen response to direct user actions (specifically, dragging the scroll bar, finger-scrolling on a touch screen, or dragging an object) do not count as animation under this section. By unmoderated, I mean that adding inertia for realism would be considered animation and therefore not exempt from this section.

[alastc]

Well, we could specify size & duration.

That's where we got stuck previously, how do you specify size across devices & zoom levels? How do you specify duration if it is triggered by user-action (e.g. scrolling). (See the previous issue, picking a particular comment around the right place.)

Animation-from-interactions was put forward with a primary focus on vestibular disorders, and it appeared that small animations (e.g. icons changing on hover) were not triggers. So having a minimum size (at least) seems necessary for applying it at A/AA level.

Bringing in attention impairments is interesting, but we would still need to go through a process (i.e. review research) about what does and does not impact people. I've added that to our 'Research needed' page.

And the more I think about it, the more I think that, since some people can be seriously disturbed by animation of any kind

On the other hand, animation can be a very useful learning tool. For example, my 4 year old immediately worked out how to bring back the game he was playing on an iPad (after hitting 'home' by accident) because the OS animated the app shrinking into the dock. Animation is a tool with positive and negative effects. Perhaps an SC centered around the preference would be a better approach.

[mraccess77]

Regarding jiggling icon sizes - icons can often change size with RWD and they do impact some users. An example can be found here https://www.fcps.edu/ Warning jiggling icons on hover and focus near the bottom of the page.

[guyhickling]

That's where we got stuck previously, how do you specify size across devices & zoom levels?

@alastc I don't think we need to have any exceptions to this. The operating system switches for animations don't give users a graduated list of choices. The user just enables the switch if they want to avoid animations, they aren't asked to decide if they want some and not others. If they have decided they don't want them and set the switch to say so, then we should respect that. We shouldn't say "Ok, we will stop you seeing some animations but you are jolly well going to see others whether you like it or not!" They asked for not seeing them, so do it. Most animations are only decorative, they aren't for passing information not otherwise provided in adjacent content, but see next paragraph:

animation can be a very useful learning tool

Where an animation is used for teaching or other informational purpose, the developer can still provide a button or similar means to start it running (under the control of the media query so only these users see the button). The difference now is anyone who set the system switch can choose whether or not to run it, depending on whether they think they can cope with it or not at the time.

The critical point here is that they can start it when they are ready, rather than have it thrust on them without choice as soon as the page opens or on some other trigger out of their control. The default should - if the user has set the switch - be to not run or start any animation because that's what the user has asked for.

For example, my 4 year old immediately worked out....

But I'm quite sure that if your 4 year old was subject to seizures triggered by some animations you would set the "prefers-reduced-motion" switch on every computer you have in the house! Unfortunately, with today's internet as it is, you would still have to vet every website before allowing your child on it to check that there were no such animations - and if in doubt whether a particular example was safe for them or not, you almost certainly wouldn't let them onto that website rather than risk it! What some of us are wanting to do now is to progress to a safer internet where this group of disabled people (and many other users including myself) can enjoy websites like everyone else.

I would also just like to reiterate, in case anyone still has the wrong understanding about this, that it is incorrect to think that such an SC would stop developers using animations. It does NOT stop them, it will only require developers to insert a one-line media query to test for "prefers-reduced-animations" and not show an animation if set.

[alastc]

I don't think we need to have any exceptions to this

In a consensus process we need to persuade those who disagreed with adding it at level A/AA.

As Patrick mentioned, it is not a 1:1 relationship between the user-need and setting a reduced-motion preference. A sledge-hammer solution (like just moving the current one to level A/AA) would catch many animations that are not a problem (or create extra work putting those behind a media query) which means it is creating false-positives.

In this case, moving it forward involves showing evidence of impact from a certain size/speed and we need to define size in a web context.

[CharlesBelov]

In this case, moving it forward involves showing evidence of impact from a certain size/speed and we need to define size in a web context.

@alastc: What would be the ethics of a study to show such evidence of impact? Were I to take part in such a study, it would cause me harm as well as be impractical - after each ill-feeling-triggering incident, I would have to wait over half an hour for my eyes to return to normal for the next test.

In the meantime, while this proposal is argued, I am regularly randomly subject to websites that, even if they do not make me feel ill, at the very least distract me from my task. We are currently going through a time where we are being asked to believe people on a wide variety of social issues. That includes disability. I am requesting that I be believed that unsolicited animation causes me various issues; that it does so more often than not; and that if I have requested through my operating system that animation not be served to me except upon my specific request, that this is sufficient and that websites do not need a study in order to be required to accommodate my disability.

I respectfully suggest that the W3C Code of Conduct play heavily in a decision of whether to make this A, AA, or AAA.

[patrickhlauke]

We’re then still coming to “if a site doesn’t honour prefers-reduced-motion and turns off all animations then it’s illegal”.

Again, “prefers reduced motion” is not the same preference as “turn off all animations”. So it’s about defining what needs to be reduced, and what an appropriate vs inappropriate motion looks like in unambiguous terms. Otherwise it’s by far too draconian as a normative requirement.

[patrickhlauke]

Random anecdotal point about users on windows accidentally/unexpectedly setting prefers-reduced-motion for whatever it’s worth https://developer.paciellogroup.com/blog/2019/05/short-note-on-prefers-reduced-motion-and-puzzled-windows-users/

[alastc]

What would be the ethics of a study to show such evidence of impact? ... In the meantime, while this proposal is argued, I am regularly randomly subject to websites that, even if they do not make me feel ill, at the very least distract me from my task.

Without wanting to make up the methodology on the fly, I assume such a study would not have to force people to view animations, it could be keeping a log of animations they are "randomly subject"ed to, and what level of symptom it triggered.

The issue is not whether there is an impact, that is believed and understood. That is why I brought the SC to the group in the 2.1 development. The issue is what specifically triggers symptoms, and how we draw a line around that. Otherwise, as Pat said, we would be (trying to) make something illegal when we know that the preference is not a 1:1 fit, and it would be catching false-positives.

You (and Nate) were a valuable part of the original discussions on this SC, but AFAIK there hasn't been any advance since that time.

The code of conduct is a useful document for ensuring we have productive & respectful discussions, but the more relevant document for levels is the wiki page.

[mraccess77]

In terms of the Windows setting - I find it blocks too much for me -- it does block animations I don't want but also seems to block a few things that I do want. I have tweaked my performance settings as discussed in the article but am forced to leave the animate controls and elements inside windows on -- I would like more fine control. For me certain animation is not a health issue but more of a "makes me tired or distracted" issue.

[CharlesBelov]

@patrickhlauke:

Again, “prefers reduced motion” is not the same preference as “turn off all animations”. So it’s about defining what needs to be reduced, and what an appropriate vs inappropriate motion looks like in unambiguous terms. Otherwise it’s by far too draconian as a normative requirement.

Mac uses the terminology "Reduce Motion." Windows uses the terminology "Show animations in Windows." I'd hazard a guess that the specific wording prefers-reduced-motion was based on the fact that the technology was only available on Mac (in Safari) at the time it was added.

@alastc:

The code of conduct is a useful document for ensuring we have productive & respectful discussions, but the more relevant document for levels is the wiki page.

Thank you for the reference to the wiki page. I'm missing where it says how to appropriately choose a classification; it seems more to analyze the relationship between classifications and levels. It also states the page does not necessarily reflect consensus. That said, here is my analysis of the different categories, for discussion:

Essential: Firefox and Safari support user style sheets. I do have animation-duration: 0 and transition-duration: 0 set in my user style sheet, but it does not work for animated gifs or JavaScript animation.

In theory, one could install browser extensions to disable animations. I only found one such extension for Firefox, and it was not under Firefox's security review, so I would be hesitant to install it. Ideally, Firefox themselves would be able to add a feature to defeat specific JavaScript commands.

So, right now, a big Maybe.

Easy: All-or-nothing is easy; if a study is needed to support, no, since different site visitors may have different levels of tolerance, and it would be difficult to come up with a consensus value.

Invisible: If I'm interpreting the bullet points correctly, yes for people who allow animation; no for people who don't.

All: Not sure why the page gives "no" for 2.3.3. In theory, an operating system which had zero animation is possible.