How to Design a WCAG-Friendly Lottie Block for Rise 360

Animated GIFs can add a lot of life to a Rise 360 lesson, but WCAG has a very real catch: if motion auto-plays for more than five seconds, learners need a way to pause, stop, or hide it.

Design with me: Building a WCAG-Compliant Animation Block for Rise

That requirement does not mean your courses have to become motionless. But it does mean we need to be more intentional about how we build animation blocks.

The accessibility problem with animated GIFs in Rise#

Nicole started this build from a real course constraint: a series of Rise courses that needed to be WCAG compliant, but also used animated GIFs to make the experience feel more polished and alive.

The specific issue was WCAG’s requirement for a pause, stop, or hide mechanism for auto-playing movement that lasts longer than five seconds. In plain instructional design terms: if the snowflake keeps spinning, the learner needs control over it.

That is where standard animated GIFs get awkward.

You can technically research ways to pause a GIF, but as Nicole found, those approaches tend to get complicated fast. They can be messy, clunky, and not especially elegant inside a Rise lesson.

The better path for this experiment was to stop treating the animation as a GIF at all.

The inspiration: a built-in pause button#

The reference point for this block came from the Material Design 3 website, where animated examples appear directly on the page with a small pause button in the corner. The animation still adds movement, but the animation can be stopped if needed.

That was the core design goal:

• Keep animation available in the Rise course
• Add a pause/play mechanism for accessibility
• Make the control feel like part of the block, not an afterthought
• Let authors swap in their own animation files

Why Lottie instead of GIF?#

The build shifted toward Lottie animations because Lottie files are much more controllable than GIFs.

Nicole was using Lordicon as the animation source, which many Rise designers already use for animated icons. Lordicon animations can be exported not only as GIFs, but also as Lottie files.

A Lottie file is JSON. Instead of being a fixed animated bitmap like a GIF, it’s a set of instructions for drawing and animating shapes. That opens the door to more flexible controls, including playback behavior.

For this proof of concept, Nicole chose a snowflake animation from a Rise course called The Snowflake Was Made in a Lab. The original Rise lesson had a static snowflake icon, making it a clean test case: replace the still image with a Lottie animation, then work toward a WCAG-friendly pause/play interaction.

The block goals#

Before building anything, Nicole defined three practical requirements for the custom block:

1. Authors should be able to upload their own Lottie animation file.
2. Authors should be able to control the animation color and size.
3. The block should incorporate a play/pause button to support WCAG accessibility.

Trying to prioritize all three requirements at once can make troubleshooting much harder, especially when you are working with AI-generated code. Nicole tackles each one step-by-step.

Step 1: Create the new Mighty Studio template#

Nicole started in Mighty Studio by creating a brand-new template.

In the template setup, she named it: “Lottie animation.”

Then she added keywords to make it easier to find later:

• MC challenge four
• Lottie animation
• GIF
• image

That keyword list is a small but useful authoring habit. If you are building a growing set of custom Rise blocks, your future self will appreciate being able to search by the old term you used to use, like “GIF,” even if the block now uses Lottie.

Step 2: Give the AI the full vision, then narrow the task#

Nicole connected Mighty Studio to Claude and started by describing the final block she wanted to create.

The important move here was not asking the AI to build everything immediately. Instead, she gave it the overall context first, then narrowed the first task:

Let’s first focus just on displaying the Lottie image in the block.

That is a useful pattern when you are working in Mighty Studio. Give the AI enough context to understand where the block is heading, but keep the first implementation small enough to test.

For this first pass, Nicole also decided to provide an actual Lottie file for the AI to reference. Since Lottie is JSON, having a real file available gives the assistant something concrete to work from instead of guessing at the structure.

Step 3: Test the Lottie upload in authoring test mode#

Once the first version of the block synced back into Studio, Nicole turned on authoring test mode.

The test workflow was:

1. Turn on authoring test mode.
2. Find the snowflake Lottie file.
3. Upload the file into the block.
4. Check whether the animation displays.

The first result was not glamorous: Could not load animation.

That is normal for this kind of custom block work. The important part is what happened next.

Step 4: Use Inspect to troubleshoot the block#

Instead of guessing, Nicole opened the browser’s inspect tools and looked for console errors.

The console showed an error related to change state. The block was trying to work with pause button state before the pause button existed.

In other words, the AI had jumped ahead. It tried to include logic for a later feature before the basic upload-and-display behavior was working.

Nicole copied the console error and sent it back to Claude with a clear correction:

• The block does not need to capture state yet.
• There is no play/pause button yet.
• The only goal right now is to upload the Lottie and display it in the block.

This is a great reminder: AI can help you move faster, but it still needs direction. If it adds a method that does not exist or anticipates functionality you have not built yet, the browser console becomes your best collaborator.

Step 5: Retest with a clean upload#

After the fix synced back to Mighty Studio, Nicole restarted authoring test mode to get a clean test.

Then she:

1. Removed the earlier failed upload.
2. Uploaded the snowflake Lottie again.
3. Checked the block preview.

This time, the animation displayed correctly.

That is the first major milestone: a custom Rise block that can accept and render a Lottie file. No color controls yet. No size controls yet. No pause button yet. Just the animation, working.

It sounds basic, but it’s the foundation everything else depends on.

Step 6: Add author controls for color and size#

With the Lottie display working, Nicole moved to the next layer: author-editable styling.

The goal was to let the Rise author control:

• The Lottie animation color
• The animation size

After syncing the next version, she started fresh again in authoring test mode and confirmed that the existing animation upload still worked. Any time you add a new feature to a custom block, make sure the old feature still behaves.

Then she tested the new color control by choosing a purple close to the Mighty brand color. The color picker worked, and the Lottie animation updated.

Next came the size control.

Nicole tested:

• 30 for a tiny snowflake
• 600 for a much larger version

At the larger size, the animation auto-scaled based on the available screen size, which was the desired behavior. That matters in Rise, where the same lesson needs to hold up across different viewport widths.

Step 7: Add the pause/play button#

With the Lottie file displaying and the visual controls working, Nicole was ready for the most important piece: the pause/play control.

This was also where the original accessibility goal came back into focus.

Rather than forcing the button to appear on every animation, Nicole decided to make the control optional. Authors could turn the pause button on or off from the authoring form depending on whether they needed it.

She also wanted the button to belong to the overall block rather than feeling like it was attached directly to the animation.

The final design requirements were:

• A toggle to show or hide the pause/play button
• A color control for the button
• A default gray button color
• The button positioned within the overall block
• The button located in the bottom-right corner of the block

The first test looked promising. The button appeared exactly where Nicole wanted it: inside the block, but visually separate from the animation itself.

At this point, the basic accessibility mechanism was in place.

Step 8: Test the block in an actual Rise course#

Once the block looked good in authoring test mode, Nicole released the draft and moved into a real Rise course.

This is an important step when building custom blocks: passing the authoring test is not the same thing as knowing the block will work in the actual course environment.

Nicole added the new Lottie animation block to her course and began testing the controls.

First, she changed the animation color and uploaded the snowflake Lottie file.

Then she adjusted the animation size to something more appropriate for the course. After a little experimentation, she settled around 100 for the snowflake.

She also enabled the play/pause button and tested the button color.

The block was behaving as expected, but this real-course test revealed another useful opportunity: more control over the pause button itself.

Step 9: Add control over the pause button size#

Nicole decided that authors should also be able to control the size of the pause button.

She tested a button size of 40 and confirmed that the new control worked without breaking the other functionality.

Another nice detail emerged during this test: the button's position responded to the overall content width of the block. Because the button sits in the bottom-right corner of the container, changing the block from full width to a smaller content width also changed where the button appeared.

That gave the author another way to control the visual relationship between the animation and its accessibility control.

Nicole ultimately preferred a smaller content width because it made the connection between the animation and the pause button much clearer.

Step 10: Take advantage of versioning#

One of the more satisfying moments in the build came when Nicole returned to the existing block after releasing the updated version.

She didn't have to delete the old block and start over.

The new button-size control was already available in the existing block.

That's a huge benefit of working with custom templates in Mighty Studio: once a template is updated and released, existing implementations can pick up the new functionality rather than requiring authors to rebuild everything from scratch.

For anyone experimenting with custom blocks, this is a good reminder to think beyond the first version. You can continue refining a block as you discover better controls or new authoring needs.

Step 11: Finalize the block#

With the animation, color controls, sizing, pause/play functionality, and button styling all working, Nicole was ready to call the block finished.

Her description for her MC Challenge submission summed up the purpose of the block nicely: upload a Lottie JSON animation file with the option to include a pause button for WCAG compliance.

Why this matters for accessibility#

Mighty Studio gives you a path to prototype custom blocks that can go beyond native Rise behavior, but WCAG compliance still depends on the final implementation, testing, and how the block behaves for learners.

For this kind of animation block, the accessibility checklist should include:

• A visible pause/play control for auto-playing motion over five seconds
• Clear button state so learners know whether animation is playing or paused
• Keyboard access to the control
• Screen reader-friendly labeling
• Visual placement that does not obscure important content
• Testing in the actual Rise course, not only inside the block editor

The big design principle is simple: motion should be optional for the learner, not mandatory.

A reusable Lottie block gives you a more sustainable pattern than one-off GIF workarounds.

You can keep the visual energy of animation while moving toward better learner control. You can also give authors practical settings, like upload, color, and size, so the block can be reused across lessons instead of rebuilt every time.

The key is to build in small, testable layers:

1. Make the animation render.
2. Add the authoring controls.
3. Add the learner control.
4. Test for accessibility.

That sequence keeps the work manageable and makes troubleshooting much less mysterious.

A practical takeaway#

If your Rise course uses animated GIFs that loop for more than five seconds, pause and audit them before publishing. For your next animation-heavy lesson, consider whether a Lottie-based custom block could give you the same motion with more control.