Apps Don’t Scroll

A timer has one job: start, stop, reset. Nobody reads a timer — you operate it, usually in a hurry, usually one-handed. Steven Hoober watched 1,333 people use phones: 49% held them one-handed, and 75% of all taps were thumb taps.

A thumb has an easy arc near the bottom and a far corner it can barely stretch to. Put Start in the easy arc and the timer disappears into muscle memory. Let a scroll push Start out of that arc and you have taxed the one control the whole screen exists for.

Now the opposite. A feed is a stream with no natural end. You read it. It is taller than the glass on purpose, and scrolling is the mechanism, not a bug. It must also reflow into a 320px column and survive a 400% zoom, because it is content.

But scroll has its own failure. Infinite scroll lifts raw engagement, then quietly breaks comparing and coming back. Etsy dropped it in 2012 and engagement went up, because people could navigate again.

Here a rule breaks and judgment starts. A dashboard has tiles up top and a twelve-column table below. Tool or document? Both — in different regions. The frame is a tool: filters and tabs stay put while you work. The table genuinely needs two dimensions, and WCAG names data tables among the regions exempt from reflow.

But exemption is permission, not a plan. A twelve-column table shoved onto a phone as a sideways-scrolling strip is the pattern people find clunky. Reflow each row into a card instead — every value reachable, nothing swiped for.

A canvas with tool rails down its edges. You manipulate content, and the controls must stay in view the whole time. The moment a brush size scrolls away mid-stroke, the tool has failed you.

This one isn’t our opinion. It is WCAG’s own wording for what reflow exempts: interfaces where it is necessary to keep toolbars in view while manipulating content. Apple reserves full-screen, no-chrome layouts for exactly this immersive focus. One caution rides along: a pinned bar must never cover what a keyboard user has selected.

This is the one that catches good designers. A checkout is a tool — you operate it — but it is long. The instinct is to let it scroll. Cut the fields first: the average checkout shows 14.88 where 7 or 8 would do, and completion drops 4–6% for every field past the eighth.

Then, for what survives: a long tool does not grow taller, it grows into more scenes. Split it into steps, each one a calm viewport. Multi-step converts around 13.9% against 4.5% for one long page. But know the other edge — a three-field form should never become a wizard.

Five scenarios, one method. Three questions settle any new screen, in order. Are you reading it, or operating it? Reading means document: it scrolls, and it must reflow. Operating means tool: it stays put in one viewport.

Would a scroll hide a control you need right now? Then it is a tool failing — re-lay-out rather than scroll. And is any region genuinely two-dimensional — a table, a map, a canvas, a game? That region is exempt and may scroll inside a frame that does not. Everything after those three is detail.

Use 100svh, not 100vh. 100vh means the large viewport — the screen as if the toolbars were hidden — so on load, with the bar showing, it overflows and the bottom bleeds away. 100svh is measured with the toolbars showing: it always fits. Reach for 100dvh only when you want the stage to grow as the bar retracts.

And when one screen honestly is not enough, add scenes rather than height: two panels side by side, a slim bar above a grid, an overlay that takes the frame for one task then leaves. Then the only test that counts: open it on a real phone with the toolbars showing.