E5.01.3hide-on-scroll app bardesign

Hiding the top bar on scroll makes Back harder to reach

Aliases: collapsing toolbar · scroll-away chrome

What it is

To give vertical space to content, many interfaces tuck the top bar away on downward scroll and restore it on the way up. A hide-on-scroll app bar saves one bar’s worth of height and spends the persistent presence of Back, the title, and page actions. The issue is not whether the bar occludes copy. It is that leaving the page becomes a conditional target: scroll the other way first, then tap.

Why it happens

Back is meant as a standing exit. Mid-read, people expect the exit to still sit where they last saw it. Hiding binds that exit to scroll direction — only an upward move, or a return to the very top, brings it back into hit range. Leaving mid-page becomes two steps: retrieve the bar, then press Back. An edge swipe may absorb some of that demand; without a swipe, or when a horizontal pager steals the gesture, the only path is reverse scrolling. In a long list the reverse distance is unknown, so people overshoot, fail to find the bar, or conclude this page has no Back.

The policy also fights scroll intent. Downward movement means “keep reading”; the system reads it as “you do not need to leave yet”. That guess often holds in a feed. It fails when a stretch of reading is supposed to be checked against the parent, or followed by share or dismiss. Appearance further depends on velocity thresholds and direction jitter: a small reverse is ignored, a fast reverse interrupts reading, and reachability of the exit becomes a timing problem.

Where it stops holding

Immersive reading, full-bleed media, and timelines can hide by default if leaving does not depend on the bar — a system back gesture, an explicit dismiss at the bottom, or an in-content exit. Short pages, forms, and wizards should not hide Back: the job is to finish and leave, the scroll distance is small, and the recovered height is not worth an uncertain exit. Nested scrolling (a horizontal gallery inside the page) misreads direction, so the bar flashes or refuses when the user was not trying to leave. If accessibility focus remains on a Back control that has moved off-screen, hiding produces the worse state of focusable-but-invisible.

Applying it

  • List every path that leaves this level. If the top-bar Back is the only visible exit, do not hide the whole bar on scroll; compress the title at most, keep Back.
  • If the bar must hide, give Back a path that does not depend on scroll direction: an edge swipe, a bottom dismiss, or a leave control at the end of the content.
  • Make the reveal sensitive to a slow upward nudge so people need not fling to see the exit; do not let horizontal scrolling drive vertical hiding.
  • How to check: from mid-list, run “leave this page immediately” and “share, then leave”. Count how often reverse scrolling is required before Back can be tapped. Each reverse scroll is an exit that became conditional. Walk the same flow with assistive technology and confirm focus never lands on a control that has already left the screen.

Related

  • Within the group: E5.01.1 The top bar carries title, back, and global actions · E5.01.2 On large phones the top bar sits in a hard-to-reach zone
  • Adjacent: E5.07 Infinite Scroll · E5.09 Back to Top
  • Search terms: hide-on-scroll · collapsing toolbar · back affordance

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E5.01.3