Reading progress

The bar answers a question a scrollbar answers badly on a long page and not at all on a phone: how much of this is left? It is scroll-linked, meaning the fill is a function of position rather than of time. Scroll up and it goes back down, which is what separates it from an animation that a scroll position merely starts.

The arithmetic is one line and the honesty is all in which numbers you put in it. Divide the distance scrolled by the total scrollable distance and you are measuring the document, which includes the comments, the newsletter box, the related stories, and the footer. That bar reads 60 percent while the reader is on the last paragraph, which is worse than no bar, because it promises another six minutes of an article that has already ended. Measure the article element instead: the bar should be full when the last line of the piece reaches the bottom of the viewport, and it should simply stay full while everything after it scrolls by.

On the web platform it no longer needs a scroll listener. A scroll-driven animation with animation-timeline: scroll() runs the fill off the scroller’s own position, off the main thread, and degrades to a static bar where it is unsupported. Where a listener is still used, it belongs behind a throttle, because it fires far more often than the screen refreshes.

Treat it as decoration in the accessibility layer. A progress bar that announces a new percentage on every scroll event is unusable with a screen reader, and the information is already available in a way that does not need announcing, so aria-hidden is usually the right answer rather than role="progressbar". Two neighbours are worth keeping apart. Scroll spy also reads scroll position, but it reports which section you are in rather than how far through you are, and it is navigation rather than reassurance. A progress bar proper reports a task the interface is performing, where reading progress reports something the reader is doing and the interface is only watching.