Scrollytelling web design: building a story out of scroll steps
Scrollytelling ties a story's progress to scrolling: as each block of text arrives, a graphic, map or photo beside it changes to match. The reliable pattern is simple: a sticky graphic, a column of short text steps, and one change per step. Keep the text in normal page flow so keyboards and screen readers can read it, and give a still version to anyone who has asked for reduced motion.
Where scroll storytelling came from
The form grew up in newsrooms. The New York Times' "Snow Fall", published in 2012 about an avalanche in Washington State, is the piece most often credited with making long, immersive scrolling stories mainstream, mixing text with video, maps and animated graphics. Data journalism teams then refined a more disciplined version: a chart pinned in place while paragraphs scroll past, each paragraph moving the chart to its next state. That pattern is what most people now mean by scrollytelling.
The structure of a scroll story
- Write the story first, as plain text. If it doesn't work as a sequence of short paragraphs, the scrolling won't save it.
- Break it into steps. Each step is one idea and one change to the graphic: a highlighted line, a zoom to a region, a new photo.
- Decide what stays fixed. Usually one graphic or map, made sticky, with the text column scrolling past it.
- Open and close in normal flow. An introduction before the sticky section and a conclusion after it, so the story has edges.
- Keep it short. Somewhere between five and fifteen steps covers most stories. Beyond that, split the piece or use chapters.
Building it: sticky graphic and text steps
The layout is CSS. Put the graphic in a container with position: sticky and top: 0 so it stays in view while its section scrolls, and put the steps in a column beside it on desktop or over it on phones. The changes need a little script: the Intersection Observer API reports when each step crosses a point on the screen, without a scroll handler running on every frame, and the callback switches the graphic to that step's state.
| Choice | Do | Avoid |
|---|---|---|
| Scrolling | Let the browser scroll normally | Hijacking the wheel or snapping between steps |
| Text | Real HTML in the page flow | Text drawn into the graphic or canvas |
| Changes | One change per step, with a short transition | Several things moving at once |
| Phones | Text cards over a full-width sticky graphic | Side-by-side columns squeezed to 180px |
| Ending | A final static summary of the graphic | Leaving readers on a half-animated frame |
Keeping it accessible
- Keyboard. If the text is in normal flow, Page Down and the space bar move through steps just as a wheel does. Anything interactive in the graphic must be reachable by Tab.
- Screen readers. The graphic's changes aren't seen, so each step's text has to carry the point on its own. Give the graphic a text alternative for each state, or describe the change in the step.
- Reduced motion. Under prefers-reduced-motion, swap transitions for instant changes, or show each state as a still image beside its paragraph.
- Zoom. At 200% and above, a sticky graphic can fill the screen and hide the text. Let it stop being sticky below a certain height.
Scrollytelling examples that work, and when to skip it
It suits stories with a spatial or visual change at their heart: a route on a map, a chart that builds, a building's history phase by phase, a product's parts assembled one by one. Annual reports, campaign pages and museum or exhibition sites use it well. It's a poor fit for information people return to, like prices or opening hours, and for pages where readers want to skim. A narrative scrolling website is also expensive to maintain; changing one step can mean re-checking the whole sequence. For lighter motion, see scroll animations on websites and parallax scrolling.
Scrollytelling in Anticode
Anticode doesn't build scrollytelling on design-engine pages. Those pages ship with no scripts, so there's no way to switch a graphic step by step, and their sections are laid out as a standard page. Their CSS motion is limited to entrances and small scroll-linked movement, such as a parallax drift you can set in the layout editor.
An app build can approximate a scroll story. The model writes the whole page as one HTML document with its own JavaScript, so you can describe the steps and the graphic and ask for a sticky layout. Apps run in a strict sandbox with no network, so the data and graphics have to live in the app itself, drawn with SVG or canvas, and outside images apart from Google Fonts aren't loaded. The publish gate requires a reduced-motion rule for anything that animates, and when headless review is available, new app builds are opened at phone and laptop widths and clicked through before you see them.
Questions people ask
What is scrollytelling?
A way of telling a story on a web page where scrolling moves it forward: text steps scroll past while a graphic, map or image changes to match.
Is scrollytelling accessible?
It can be if the text is in normal page flow, each step makes sense without seeing the graphic, and motion stops for people who ask for less.
Do I need a library to build it?
No. Sticky positioning and the Intersection Observer API cover the basic pattern.
Sources
- position, MDN Web Docs, checked
- Intersection Observer API, MDN Web Docs, checked
- prefers-reduced-motion, MDN Web Docs, checked