Making Motion Inclusive

Hi, everyone.

Thanks for joining me and thanks to Web Directions for having me back.

It's a common misconception that things like inclusive design and accessibility can only come at the cost of creative details like motion, but that just doesn't have to be the case.

Whether it's micro interactions, animated illustrations, or even larger immersive animated experiences, we absolutely can be purposeful, creative and expressive with motion without sacrificing accessibility and inclusion.

It really all comes down to how we approach things.

In this session we're going to dig deep on one aspect of making motion inclusive.

And that's the prefers reduced motion, preference and media feature.

It's not the only thing we can do to make our motion inclusive, but it's one of our newer options as well as a very powerful tool.

And it tends to be a little bit misunderstood.

On the user end of things, prefers reduced motion is a user preference that most people can indicate or turn on through their operating system.

This is what it looks like an iOS or Mac OS where there's this reduced motion checkbox.

And when someone selects this preference or indicates this preference, the operating system will reduce the amount of motion that this person sees within the effects that operating system has.

So it works on the system level.

And this is available in all current operating systems, both desktop and mobile.

So Windows, Android has this as well.

The exact wording of the preference and exactly which types of effects it will well affect, depend on the system.

But overall, the same result occurs.

When you indicate this user preference at the OS level, it will reduce the amount of motion that you see in the OS effects.

And this preference is something we're able to tap into through browsers as well.

This is a current table of browser support.

And as you can see, browser support is pretty, pretty darn good.

It's something we absolutely can use in production today because the support is just it's, it's really there.

This is something that maybe wasn't the case a few years ago, but has quickly gained traction as user preferences are something we're more and more aware of, and in modern web design, as many people out there have said you know, it's just a thing that's kind of the way things are going now that everyone is spending so much time on the Web.

Respecting the prefers reduced motion preference, like any user preference isn't required in our work, but it's a great way to make our products more inclusive and expand the number of people who can safely engage with our content.

So it's a win-win kind of situation.

We can access the results of this user preference in the same way we access any media queries today.

So we can do it in CSS-however you like to write media queries, whether it be it's like this we can handle them like this in CSS.

And we can also get the value of this user preference in JavaScript as well.

Same deal, however you prefer to write media queries or find the value of media queries.

You can use the same to query the prefers reduced motion preference.

However you query this preference, it will return one of two values-either no-preference, which equates to false or reduce, which equates to true.

A common mistake is to assume that the value of false means that the person in question has opted into all levels of motion effects.

As nice as it would be if it was that straightforward, it's just not what that value means.

no-preference can have two meanings, which is why it's a little more complex.

It can either mean that the person in question has not set that preference at all yet.

Maybe they aren't aware of it or just haven't gotten around to it.

Or it can mean that that person is okay with all levels of motion and doesn't need reduced motion.

So because of that double meaning, the only value of those two that we can be absolutely sure was set intentionally by someone is the value of true.

So the value of true indicates a user preference for reduced motion, and we should provide a reduced motion experience when needed, based on that value.

So probably the next question on your mind when you hear that is like, well, what types of motion effects might require reduce motion?

Or to put it another way, what kind of animations should we reduce when this preference is indicated?

So let's do a little more digging into that and we'll start at the web content accessibility guidelines.

The web content accessibility guidelines around this fall under the guidelines for animation from interactions.

I've summarized this guideline here, and it's one that's shown up in more recent versions of the web content accessibility guidelines.

The first term in this guideline is one that might sound a bit odd at first, this idea of motion animation.

When we see that you probably think like, well, don't those mean the same thing?

Like we so often use motion and animation interchangeably in conversation.

I know I do all the time.

It's pretty common.

And in most contexts, that makes perfect sense.

But in this particular case, it is important to be specific about the differences.

So the definition of motion animation as provided in the web content accessibility guidelines is this.

You don't have to read it all.

It's a lot of words on the slides right now.

I want to call your attention to the last line in bold, where it says then "motion animation does not include changes of color blurring or opacity'.

Effectively motion animation does not include effects that don't have motion.

What they're saying here is that the term motion animation is referring to a specific subset of animation effects, specifically effects that create the illusion of motion or effectively move things, right?

And motion animation is a subset of the greater all animation.

To put it another way, some types of animation effects are considered motion animation and others, ones that use non motion effects, are not.

I often see discussions around reduce motion get over-generalized to lump all animation into the same bucket.

But as we see here, even the web content accessibility guidelines is a very specific about the type of animation that should be top of mind here.

I want to stress that none of this is a reason to decide that animation should be just left out of UX design altogether.

That's not what the web content accessibility guidelines is suggesting, nor is it what prefers reduced motion is all about.

Animation absolutely can have a positive impact on UX, usability and even accessibility when it's used purposefully.

I've done previous talks even here at Web Directions about exactly that.

And I've even written a whole book about it as well as number of articles.

And so have a few other people, so lots of places to find out about how animation can support UX and accessibility, if that's something you're interested in.

And I just want to emphasize that what the web content accessibility recommendation is all about and what prefers reduced motion helps us do is using animation, both purposefully and responsibly in the interfaces that we design.

So essentially what we're doing is taking things one level further and that's pretty cool.

Generally speaking, according to the web content accessibility guidelines, any animated effect that creates the illusion of motion, creates the illusion of physical movement, is one that could be potentially triggering for folks with motion sensitivity.

The web content accessibility guidelines recommends providing a reduced version for any motion that creates the illusion of movement.

That paints with a really broad brush though, and you wouldn't be alone if you said that that was a bit tough to get your head around.

So I think it helps to talk about some specific examples.

In my research around this, I found that there were certain types of motion effects that were brought up over and over as like the top of the list things that have been problematic for folks with motion sensitivities, or at least top of the list for the folks with motion sensitivities that I've talked to.

And I think these types of effects are a good place to start with your efforts around reduced motion, to have the most impact with your effort.

It's not an all-inclusive list by any stretch, but these are the types of effects, rather that got mentioned many times over and over in my interviews.

So I think, I think there's something to that.

At the very top of my list of potentially problematic effects is multi-speed or multi-directional movement.

And yes, that means parallax effects.

You know, the very definition of parallax is different things moving at different speeds.

So that is multi-speed and it's often multidirectional as well.

And this isn't to say that like never, ever use parallax or parallax is always bad.

There's definitely places it makes sense to use.

And it's a pretty fun effect in certain contexts.

But if you do want to use parallax effects, you should definitely provide a reduced motion version to accommodate people who've indicated that preference for reduced motion.

Spinning effects are also high up on the list.

I feel like vortex effects feels a little self-explanatory cause the vortex is definitely, I mean, that's a lot of motion going on, but spinning effects can be problematic, even if they're more subtle and maybe not something that we would consider like on the level of a vortex, for example.

My theory is that this is likely in part because.

I feel like when things spin, they often tend to spend infinitely.

That's just like a direction things tend to go.

But that's just a hunch on my part.

The kind of more practical information here is that if you have any motion effects that cause things to spin, especially if they spin infinitely, that is an effect that you want to provide a reduced version for when prefers reduced motion is requested.

It's definitely one that's going to be problematic for a lot of folks with motion sensitivities.

Spinning is just spinning it's just one of those things.

It was definitely one that came up almost as much as parallax so that's why it's second on my list.

And the third one on my list is constant motion near text.

And this is something that could be problematic for folks, even folks that have difficulty with attention and focus, it isn't necessarily just a motion, sensitivities kind of thing.

So anytime you have something that's animating constantly near text, you should consider providing a reduced motion version for that type of effect as well.

So, those are just like the top three ones that just came up over and over in my research around this.

They're definitely not the only ones.

If you want more examples of potentially problematic motion effects and you know, ways to mitigate them with a prefers reduced motion media query, this article is one that came out on the WebKit blog right around the time when WebKit started supporting the prefers reduced motion query.

And it has a lot of great examples of, you know, potentially triggering effects and some logic around how you might go about making those less problematic.

So it's a few years old now, but still a quality read.

Not on my list of top things that people have told me are problematic for them when they have motion sensitivities to motion on screen are things like animated color changes, opacity fades, essentially a whole list of non motion effects.

And this list should sound familiar.

For at least two reasons, possibly more but two that I can think of.

This is almost exactly the things that the web content accessibility guidelines calls out as not motion animation, therefore not what they're talking about when they say motion animation.

And also because these are the things we tend to reach for first, when we're doing UI animation, when we're just kind of doing maybe some baseline UX animation, you know, design that maybe just use this motion as a secondary design tool, not like the main thing, telling the story, we tend to reach for things like color fades, opacity fades, maybe very small changes of, scale things like that that would be considered non motion effects or very, very small amounts of motion.

So especially when it comes to those non motion effects, it's entirely possible to have a site that uses a whole lot of animation.

But if it's all things like opacity fades, color fades, non motion effects, it may not have any motion animation at all.

So really just back to the idea of we're talking about certain types of effects, not all animation lumped in one bucket.

So, what can we do to respect reduce motion requests?

You know, this is something that people, are users, are requestin, it's a user preference and you know, they're putting that out for us.

What should we do about it?

How do we design with this user preference in mind.

My recommended approach is to first identify potentially triggering motion effects that you might have.

Chances are for most sites this is probably a fairly short list, but regardless of how short or long that list might be, I think it's really important to get specific about which affects you are addressing.

And this is important because of the second step or the second point, which is that you want to decide on the best reduce effect based on the context.

You know, sometimes the best plan is to replace that high motion effect, that motion animation, with a non motion effect.

Sometimes the best plan is to say, remove it or create some kind of poster frames slash paused version of it.

But the context and meaning of the motion in question is what will determine what the best choice is.

Essentially there is not a one size fits all solution for reduced motion, if preserving meaning and functionality are important to you.

And I hope they are because those things are generally pretty important to the people coming to the sites that we build.

You know, people indicating this preference for reduced motion, they're not asking for a broken site.

They're not asking for a site devoid of all design details or UX affordances.

They're asking for a site that won't make them sick.

And that's a pretty reasonable request.

And considering context is key to making sure that's what we provide.

You know, context, context is king, as they say, it's very important.

Actually, it's not what they say.

Is it anyways context, very important.

Awareness of this preference is still growing as is the awareness that this preference can affect content on the web.

So the more we implement reduce motion well, the more effective this preference will be for those who need it.

So the better we use it, the better it will be for everyone.

The most common approach to reduced motion is to replace high motion effects with a non motion effect, like we see in this classic iOS transition effect, where when you go from the menu screen to open up a specific application, here's what you see.

It's a very, zoomy, very 3d, very springy, like zoom in kind of vortexy honestly, effect.

There's no spinning, but it's just very, the way the spring works, the distance it covers.

There's been articles written on like how fast the icon is moving in like the world of the operating system.

And it's, it's pretty intense.

So.

You know, based on what we've talked about so far, you can kind of see why that would be something that would be problematic for folks with motion sensitivities.

And of course, add in the fact that this is something you might see tens to hundreds of times a day, depending on how often you use your phone.

So definitely something that's going to be problematic because the high level of motion and definitely motion animation, that's going on there.

If you have set your the preference for reduced motion on the, on iOS, at the operating system level, this is what you will see instead.

So that high motion, zoom, springs situation going on is replaced with a nonmotion crossfade.

We're still doing the transition is between the same two things.

It's from the menu screen to the application that you're opening, but the effect that's used to get you from one place to the other has been swapped out for a non motion effect to be safer for those folks that have requested reduce motion from their operating system.

And oftentimes that reduced motion version can be created by, you know, it can be pretty straightforward.

It can be just swapping out the property that's animating.

So here's an example that I put together.

It's maybe a little bit of like a header animation, something like that.

We have photos coming in from two different directions and texts coming in from two different directions.

So it is definitely multi-directional motion.

And it's also pretty big.

So these are definitely something I would consider motion animation.

Definitely multi-directional.

So I'm thinking that should be pretty high up on my list as something I identify as an effect that would require reduced motion version for someone who's indicated this reduced motion preference.

So taking a quick look at kind of like some summary of the code behind this, I'm doing it with CSS transitions, but this can be done, whether you're using CSS animations, or any of the web animations API or whatever it might be.

This can be done in any of the ways that we animate stuff on the web.

So what I have is a starting state where each of these plants has been essentially transformed you know, given a translation to be slightly in a different place than it would be intrinsically.

So some are up or down and I've set a transition with a specific duration and delay to stagger them as well as a specific easing variable.

So we've defined the animation and the transition and started these plants in their starting state.

Then the end stage, this is obviously a little bit of summarized, not the exact code but the end state for all the plants is essentially go to the place you would have been intrinsically.

And you know have the opacity of one, and I put opacity of one in there to help make swapping out the animating property a little bit easier for myself.

So starting states sets the transition and starts their starting position or sets their starting position rather.

And the ending state moves it to the ending state, which triggers that CSS transition.

Taking that same effect based on the way I have that set up, I can provide a reduced motion version just by changing the beginning state, rather of that transition where I can change that transform to be a translation of zero.

So instead of saying, start up above where you would be photo, just say, stay where you were going.

Like stay in the same place your ending state is.

Don't move at all, removing the motion.

And I can change the opacity to be zero.

So now they are, the starting state is right where they would normally be right where they will end up and opacity of zero.

And I do the same with a text that comes from in and out from the left and right.

And then just by changing that starting state, I don't have to rewrite the transition.

That's still applied to the element.

Don't have to override that.

I get this version instead.

So the, the photos use the same timing, the same transition, the same stagger and the text does as well.

But instead of animating the translation on the, or that transform, I'm animating the opacity instead.

So the, you know, swapping out properties can be a great really straightforward way of creating or going from a motion effect to a non motion effect.

And that's why that tends to be the way...

That tends to be the solution that people reach for.

So very little had to change.

And like I said, this could work for JavaScript animation libraries and other ways of animating on the web as well.

Especially when you're thinking about this early on, you can set yourself up to make this a fairly easy swap.

One other thing I want to talk about is motion toggles.

You know, in the past, this was something I mostly suggested for things, you know, projects where motion is a key part of, of this, the content or the story where it's, you know, motion is heavily used as part of the design solution.

You know, storytelling experiences, dataviz, all those things you might use.

You know, rely on motion a lot more heavily to get the content and context across.

But you know, in, in recent, in recent times, I guess in recent months, I've come to realize that motion toggles, you know, I think it's something that can be useful even beyond those kinds of sites.

It can be a really useful way to essentially surface the fact to your users that you do have this preference available and that they do have the option to express their user preference for reduced motion, even right there, on your site, if you already have a settings or user preferences kind of place.

So my favorite example of motion toggles is the animal crossing site.

Not just because I played a lot of animal crossing during the pandemic or even still really.

But it's just really, really well.

So it's a site for a video game, right?

Definitely a place where using a lot of animation to tell the story is, it just makes perfect sense.

But you'll notice they also have right there at the very top in the middle, under the navigation a reduce motion toggle.

So that's there it's present visible the whole time.

If we come to the site with no preference around reduced motion set, here's what we see.

So we see the characters from the game.

We see some things that are very spinny and blurry, and vortexy even at one point we see a whole like explosion of balloon particles that take over the whole site.

You know, it's very, a lot of motion going on, a lot of motion animation happening there.

But it all, it's just really well done and fits with the whole story of the characters.

But like I was saying before, if you're sensitive to motion on screen, even though that stuff makes sense and fits the context, you know, it's still going to be a problem for you.

These effects could still make you feel sick.

So.

yuo know, that's, that's definitely something worth designing for, absolutely.

And what they've done here is they have the reduced motion toggles.

So we could either click that right there on the site.

Or so if we clicked that toggle, or if we came to this site with prefers reduced motion already indicated as a preference at the OS level, we see this version of the site instead.

Or this version of the effects.

Instead, we still have those same animations those same trans transitions, rather between the characters up top, but instead of the spinny blurry thing, we have cross fades and we can still get through the carousel of all the characters birthdays, and we still see the confetti, but the particle balloon explosion no longer happens.

And this is just what happens at the very on the homepage.

But there's lots more of this throughout the site where they've very done a really great job of replacing those high motion effects with non motion effects while still preserving the meaning and context along the way.

So another thing that's really great about this toggle is that if you didn't know anything about the operating level operating system level preference, you just came to the site, selected reduce motion, it would remember on previous visit or on subsequent visits.

So that's what you selected.

So you'd automatically see the reduced motion experience.

And you'll also notice that while we're here in the reduced motion experience, that toggle is still present allowing you to go back to the high motion experience.

Because sometimes the preference for reduced motion might not be a constant thing.

Right?

Some people may have days where, or situations or contexts where they are okay with a high level of motion and other ones where they're not.

So one of the really great things about this toggle is they've given people the option to go back to the high motion experience if they want to.

So it's, it's very much up to the user, what level of motion they see on the site.

And it's really, really well done.

This isn't the exact code behind that toggle, but Marcy Sutton has a really great example on codepen, that's part of her making accessible web apps course, which goes into the details of using modern JavaScript approaches to creating a smart toggle like this that will both tap into the prefers reduced motion user preference, if it's been expressed, if one has, if that preference has been indicated and also uses localStorage to save a user's preference, they don't have to constantly re-select the reduced motion version, if that's what they need.

So great logic here-it would be a great setup to base a motion toggle off of and pretty fun code to dig into as well.

And like I was saying, this idea of toggles is something that we're just seeing a whole lot more of.

This idea really, it's really this idea of, you know, surfacing user preferences and designing with user preferences in mind, you know, making the things we put out there on the web adaptable and just accommodating to user preferences.

So we're seeing a lot more things like this, where here on Twitter we have that exact, exact same type of toggle that we saw on the animal crossing site-where you can go in and select that preference, if you know this reduced motion preference is actually right there in your user preferences, and you could select that box here to reduce motion just for the Twitter site itself, or if you already had prefers reduced motion indicated on the operating system level, this box would automatically be checked and it would respect the preferences you set at that OS level.

So a lot of really smart things going on here with these toggles.

I think we're going to see this idea of allowing users to express user preferences, specific user preferences, even just for the site they're on, we're going to be seeing this more and more.

You know, it really just makes sense because as we're all living so much more of our life on the web, you know, of course the sites we use should accommodate our user preferences, that's just like, that makes so much sense.

So if you'd like to dig into more of the context around, like why people might indicate the preference for reduced motion and even get into, dig into a little bit more of the code behind how we can provide reduce motion effects, I wrote this article on Smashing Magazine last year, and it gets into a bit more detail around the context of what we've talked about today.

And also the stuff, the exact stuff we've talked about today.

So it could be a good one to check out if you want to dig in a little bit more to the context around why this is something that we have at our disposal for designing on the Web.

So I hope this has all helped to show you how we can be creative with motion, you know, even be really creative, things like making video games sites while also being inclusive and accessible.

The more we use the prefers reduced motion preference and use it well, the more useful we can make this preference and the safer we can make the Web for those folks that need it.

So by identifying potentially triggering motion effects and mitigating them with the reduced motion options that we've looked at today, you can expand the audience who can meaningfully participate in the projects that you make.

And that's something that definitely sounds like a good thing all around.

So thanks so much for listening.

I'm always happy to chat about UX animation and even all the things we've talked about today and more things about how we can make animation inclusive.

Always happy to answer questions and talk more and thanks so much for listening.