Reduced-motion testing should check whether someone can still understand the task when non-essential movement is reduced. Enable the preference in your test setup, repeat the same workflow and inspect what communicates location, progress and completion. A quieter animation is useful only if the product still explains what changed.
For a public SaaS demo, this creates a better question than asking whether the interface feels polished. Show the state before the action, the result afterward and the cues that remain without the original movement. A founder peer should be able to assess the task without needing to enjoy an animated tour.
The example here is a fictional project board. It is a proposed review, not an accessibility audit of Buildside or a test Uriel performed. The goal is a concrete motion review with stated limits, rather than a claim that one preference check proves the entire product accessible.
Inspect what the movement currently explains
In the fictional board, moving a card to another column makes it slide across the screen. Opening the card expands a panel. Finishing an item triggers a burst of decoration. A loading indicator rotates while the saved result is pending.
Those effects do different jobs. The sliding card may communicate a location change. The panel transition may explain where a view came from. The celebration adds emphasis, while the progress indicator signals unfinished work. Listing those jobs helps avoid treating all motion as one setting to shorten.
For each effect, write down the information a user might lose if it vanished. If removing a transition leaves no clue where the card went, the task needs another cue. If removing a celebration leaves the completed state perfectly clear, the decorative effect can be considered separately from that essential status.
Confirm the preference in the actual test setup
MDN describes prefers-reduced-motion as a way to detect a device setting that asks for less non-essential motion. It distinguishes a reduce preference from no preference being expressed. The preference does not automatically redesign an application's effects; the implementation must respond to it.
Record the browser, device setting and product version you used. If you use a supported browser emulation control, label the result as an emulated preference. Also check the relevant device setting when that is part of the product's supported environment. A screenshot of a settings switch does not establish how the application behaved.
Repeat the task after the preference changes. If the application reads the preference only when loading, note that behavior and test the supported reload path. Do not describe a silent recording as proof of reduced motion when the animation simply did not appear in the captured frames.
Follow the moved card without relying on its journey
Start the fictional test with a named sample card in the first column. Move it through the product's supported control and inspect the destination. The card's title, column name and saved state should make the result understandable after the motion is gone.
A proposed reduced-motion version might replace the long slide with an immediate state change and a persistent destination cue. That is a design option for this example, not a universal prescription. The useful test is whether a reviewer can answer where the card is now and what happened to the original position.
Inspect a crowded board too. A movement that looks clear with one card may conceal a confusing location change among many similar items. Use disposable sample data with recognizable labels. The public demo can show that harder condition without exposing a customer's real project names or activity.
Keep the panel's relationship to the task clear
Open the sample card and examine the details panel. If the original interface zooms into the card, a reduced-motion version still needs to identify which item is open and how the user returns to the board.
For the fictional review, inspect the panel title, the visible close control and the board state after closing. If the context disappears, record that as an explanation problem rather than immediately adding another animation. A stable title and a clear return path may solve a different part of the task.
Keep input methods distinct in the record. A successful pointer walkthrough does not prove keyboard focus behaves correctly, and a motion preference does not answer that question on its own. You can flag the separate keyboard review without claiming it was completed during this exercise. State what the recording actually shows.
Preserve status while reducing progress animation
The rotating indicator is worth examining separately because unfinished work still needs an explanation. If the original rotation is removed, the interface should continue to distinguish pending work from a saved result or an error.
In the fictional board, a proposed quiet state could show a stable progress symbol with plain text describing the action. Inspect what happens when the request takes longer than the ordinary demo. Does the status remain visible, and can the user tell whether another action is needed?
This is not a timing benchmark. There is no universal duration selected here, and no claim that every animated indicator is inappropriate. The point is to test the product's chosen response under its supported conditions. Replacing motion with silence can create a new uncertainty if movement was the only sign that work remained pending.
Examine effects that enter through other components
A board can honor the preference while a chart, modal library or embedded walkthrough continues to move. Include the components actually used in the task rather than assuming a single stylesheet covers every rendered surface.
For the fictional review, open the summary chart and the help panel after moving the card. Record which component produces each effect and whether the preference changes its behavior. Use the component's current documentation when you investigate a repair. Do not infer support merely from a setting with an accessibility-related name.
Keep the scope bounded. You do not need to explore every screen to publish a useful observation about one workflow. You do need to avoid describing that observation as an application-wide result. List unreviewed surfaces when they matter to the public claim, especially when a viewer could reasonably expect them to behave the same way.
Share the comparison as a task review
A useful public recording could show the same sample card before and after the preference is enabled. Keep the input data and task stable. Explain which movements changed, which information stayed visible and which part still needs work.
Buildside offers a community context for sharing product work. If you bring this comparison to founder peers, ask whether they can identify the moved card, its destination and the completion state from the quieter version. That is a more reviewable question than asking whether the animation looks modern.
Do not require someone to watch uncomfortable movement to provide feedback. Describe the example in text and provide a still comparison where that helps. The recording is supporting material for the task, not a reason to make participation depend on replaying every effect.
Tie the release note to the observed change
After a repair, repeat the original task and the reduced-motion version. Check that the card still moves through the intended workflow, that the panel still identifies the item and that pending work remains distinguishable from completion. Preserve the conditions that made the earlier issue visible.
A bounded release note might explain that the board now uses a quiet location change when the tested preference is enabled, while keeping a persistent status cue. That is a proposed wording pattern, not a claim about a shipped product. Name the reviewed surface and the remaining checks instead of declaring the whole app accessible.
For the next public demo, choose one movement that currently carries information. Write down what that information is, then verify how a person receives it with reduced motion. The strongest improvement may be a clearer task, even when the most visible result is less animation.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
