A phone layout and a stacked fallback from one list of steps
The code scrolls nothing here: it counts what each version builds. The first panel's chart is hidden from screen readers because the steps carry the facts (next example); the stacked version's charts keep their labels.
Most readers of a public story arrive on a phone, and some cannot or will not watch it move. Reduced motion, a layout that fits 320 px, a version that needs no scrolling trick, and text that carries every number for a screen reader are part of the story, not extras.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write durationFor(reduced, ms) that returns 0 when reduced is true and ms otherwise, and returns 0 for a negative or non-number ms too. Test five inputs.
Write missingNumbers(labels, text) that returns the numbers in the labels that the text does not contain, like the third example. Test it with a label list that is empty and with a label that has no digits.
Explain it without notes
How does a page honour prefers-reduced-motion, and what must stay the same?
How do you make the chart fit a 320 px screen, and why is a sticky chart a problem there?
What is a stacked fallback, when is it used, and what does it need?
What does a screen reader user need from a scrolly story, and what should you avoid?
Preview
Console
Nothing logged yet.Expected console output
scrolling story: 1 chart(s), 5 steps of text, needs IntersectionObserver: true
stacked fallback: 5 chart(s), 5 steps of text, works without IntersectionObserver: true
chart width inside the 290 px phone frame: 290 px, height: 203 px