Why scroll animations hide content from some visitors

A live client site, July 2026. With reduce motion on, eight blocks never appeared: About, Services, Areas, Testimonials, FAQ, the call to action, and the entire footer.

Not slow. Not glitchy. Blank, permanently. Scrolling didn’t help, waiting didn’t help, and the content was sitting right there in the page’s HTML the whole time at zero opacity.

The site was perfect on every machine anyone had tested it on, because none of those machines had the setting turned on.

It comes from an interaction between three reasonable things: server rendering, an animation library, and a considerate branch in the code.

The reveal wrapper asks whether the visitor prefers reduced motion. On the server that question has no answer yet, so it comes back false, and the server renders the element with the animation library’s starting style baked in: opacity zero, waiting to be faded in.

Then the page reaches the browser, the answer flips to true, and the component returns a different kind of element. An animated div becomes a plain one. React sees the same position in the tree, reuses the existing DOM node, and updates the properties it knows about. But that opacity was written straight into the element’s style by the animation library, not passed as a property React is tracking. So nothing ever clears it.

The branch that was there to protect reduced-motion visitors is the exact thing that breaks the page for them.

Turn the setting on, then hard reload. Both steps matter, because the bug happens during the initial render and you won’t reproduce it by toggling mid-session.

1. 01On a Mac: System Settings, Accessibility, Display, then switch on Reduce motion. On Windows: Settings, Accessibility, Visual effects, then turn off Animation effects.
2. 02Hard reload your site so it renders fresh with the setting active.
3. 03Scroll the whole page, slowly, all the way to the bottom of the footer.
4. 04Look for anything that never showed up. Whole sections, images, the footer, a call to action.
5. 05Turn the setting back off when you’re done, unless you like it, in which case keep it.

If everything appears, you’re fine. If something is missing, it’s almost certainly this.

Worth doing if you ship regularly, because this comes back the moment someone adds a new reveal wrapper. The trick is to compare two runs rather than eyeball one: load the page with reduced motion on and again with it off, scroll to the bottom in both, then count the elements still sitting at near-zero opacity.

// Run the page twice, once per motion preference.
// After scrolling to the bottom, count what's still invisible:
const stranded = [...document.querySelectorAll('div')].filter(el => {
  const style = getComputedStyle(el)
  return parseFloat(style.opacity) < 0.9 && el.getBoundingClientRect().height > 100
}).length

A healthy page settles at zero stranded elements in both runs. If the normal run reaches zero and the reduced-motion run doesn’t, you’ve found it, and the count tells you roughly how many blocks are affected.

Two rules, and the first one does most of the work.

1. 01Render the same kind of element on both paths. Don’t swap an animated component for a plain one. Keep the animated component and set its transition duration to zero for reduced motion, so the content arrives instantly instead of arriving differently.
2. 02Keep the starting style identical on the server and in the browser. It gets written into the HTML, so varying it by the motion preference creates a mismatch React won’t repair, which is a second version of the same problem.

Reduced motion should mean the animation is instant. It should never mean a different component tree.

The specific mechanism here needs three ingredients together: server-side rendering, an animation library that writes styles directly onto elements, and a branch that changes what gets rendered based on the motion preference. Take away any one and you probably don’t have this bug. That combination is extremely common in modern site builds, which is why it’s worth two minutes to rule out.

The manual check catches this class of failure and nothing else. It isn’t an accessibility audit. Contrast, keyboard navigation, headings, alt text and focus order are all separate work, and a page can pass this check while failing badly on all of them.

One more honest note: respecting reduced motion is genuinely the right thing to do. The lesson here isn’t to stop honoring it. It’s that any code path you don’t test is a path where anything can be true, and safety branches are the least-tested code in most projects precisely because they feel virtuous.