Scroll animations on a website: when reveals help and when they hide content
Scroll animations on a website can make a long page feel paced and alive, or they can make visitors wait for text that should already be there. The safe pattern is a short, subtle reveal that never leaves content invisible if the animation doesn't run, switched off for people who ask for reduced motion. CSS scroll-driven animations do this without any script.
From scripts to CSS
Scroll-triggered effects started as JavaScript: listen to the scroll position, work out where each element is, and add a class when it comes into view. Libraries made fade-in-on-scroll a one-line addition, which is why it spread across so many templates. The Intersection Observer API later made detection cheaper. Most recently, CSS gained scroll-driven animations, where an ordinary @keyframes animation is tied to scroll progress with animation-timeline instead of to time.
Two kinds of scroll animation
| Scroll-triggered | Scroll-driven | |
|---|---|---|
| How it runs | Starts when an element enters view, then plays over a set duration | Progress is tied directly to scroll position; scrolling back reverses it |
| Usually built with | JavaScript and a class toggle | CSS animation-timeline: view() or scroll() |
| Good for | One-off entrances, counters, a chart drawing in | Reveals, parallax, progress bars, sticky storytelling |
| Risk | Content hidden until the script runs | Unsupported browsers simply show no animation |
When reveal-on-scroll helps
- Pacing a long page. A slight rise and fade as each section arrives gives rhythm to a page that's otherwise one long column.
- Showing sequence. Steps in a process or a timeline appearing in order can make the order clearer.
- Storytelling. Product tours and editorial features where scroll advances a narrative, often called scrollytelling, are built around it.
When it hides content
Most complaints about a scroll animations website come down to the same few failures:
- Invisible by default. If a script sets elements to
opacity: 0and the script fails, is blocked or runs late, the content stays invisible. Visitors see blank sections; some crawlers and tools may too. - Too late, too slow. Reveals that wait until an element is halfway up the screen, or take a second to finish, make fast readers wait.
- Everything animates. When every paragraph, image and button slides in, nothing stands out and the page feels unstable.
- Hijacked scrolling. Pages that take over the scroll wheel to move at their own speed break the visitor's sense of control and often break keyboard and trackpad scrolling.
- Find in page. Content that's hidden until scrolled to can confuse searching with Ctrl+F or screen magnifiers.
The CSS-only version
A scroll-driven reveal is a keyframe animation whose timeline is the element's own visibility in the viewport: animation: reveal linear both; animation-timeline: view(); animation-range: entry 0% cover 30%;. The element finishes its reveal by the time it's about a third of the way into view. Wrap it in @supports (animation-timeline: view()) so browsers without support never see the starting state, and in a prefers-reduced-motion: no-preference media query, or switch it off inside prefers-reduced-motion: reduce. Because the content is visible by default, nothing depends on the animation running.
Accessibility rules that apply
- Reduced motion
- Operating systems let people ask for less motion, and the
prefers-reduced-motionmedia query exposes that setting. Large movement, parallax and zooming can cause nausea and dizziness for people with vestibular disorders. See prefers-reduced-motion. - WCAG 2.3.3 Animation from Interactions
- At level AAA, motion animation triggered by interaction, scrolling included, can be disabled unless it's essential.
- WCAG 2.2.2 Pause, Stop, Hide
- At level A, moving content that starts automatically and lasts more than five seconds alongside other content needs a way to pause it. Scroll-driven motion stops when scrolling stops, but autoplaying loops don't.
Scroll motion in Anticode
Pages from Anticode's design engine contain no scripts at all, so any scroll motion on them is CSS. The design systems use a scroll-driven reveal for section headings, cards, products and other blocks as they enter view, and a slow drift on full-bleed hero photos, both wrapped in @supports so older browsers show the page without motion. Under prefers-reduced-motion: reduce, every animation and transition is switched off. In the layout editor's inspector you can set an element's motion to none, rise or parallax.
Since 23 October 2026 the design gate refuses to publish a page that animates without a reduced-motion rule, so a page can't ship motion that ignores the setting.
Questions people ask
Are scroll animations bad for SEO?
Not in themselves. The risk is content that stays hidden if a script doesn't run. CSS scroll-driven reveals leave content visible by default.
Can I do scroll animations without JavaScript?
Yes. CSS animation-timeline with view() or scroll() ties keyframes to scroll position. Support is growing; wrap it in @supports so other browsers show static content.
Do reveal animations hurt accessibility?
They can, if they're large, slow or ignore the reduced-motion setting. Short, subtle reveals that switch off under prefers-reduced-motion are generally fine.