The Reading Progress widget is a slim bar, fixed to the top or bottom edge of the browser viewport, that fills from empty to full as a visitor scrolls down the page. It is a small piece of UI, but it does a lot for long-form content: it gives readers an immediate, always-visible sense of how much of an article remains, which in practice keeps people reading longer and reduces the “how much more is there?” bounce that hits lengthy blog posts, documentation, and guides. Because it renders as a fixed-position overlay, it stays visible the entire time the visitor is on the page, independent of where they’ve scrolled to.
How the fill is calculated
Each instance of the widget gets its own unique DOM id and a small inline script that runs once the page loads. On every scroll and resize event — listened to on both window and document to cover themes whose CSS causes one or the other element to be the actual scrolling container — the script recalculates a fraction between 0 and 1 and sets the inner bar’s width to that percentage, updating an aria-valuenow attribute on the outer role="progressbar" element at the same time for accessibility and screen-reader support. The math depends entirely on the Track setting you choose in the Content tab.
With Track set to Whole page (the default), progress is simply the visitor’s current scroll position divided by the total scrollable distance of the document — the bar reaches 100% exactly when the visitor hits the very bottom of the page, no matter what’s on it. With Track set to Main content area, the calculation instead measures scroll progress specifically through whichever element it finds first among article, .entry-content, main, or .elementor — meaning the bar reaches 100% when the reader finishes scrolling past the article body itself, ignoring any header, footer, related-posts section, or comment area that follows. This is the more accurate choice for a “how much of this article have I read” indicator, since a page with a huge footer or a long comments section would otherwise leave the bar looking incomplete even after the visitor finished the actual content.
Setting it up
The Position control places the bar at the Top of screen or Bottom of screen; both options render as a fixed, full-width overlay above the rest of the page content (it uses a z-index high enough to sit above most theme chrome). The Track control is the whole-page vs. main-content-area choice described above, and its built-in description in the editor spells out the distinction for anyone configuring it later. Because the widget is meant to be placed once — typically in a Theme Builder single-post template so it appears on every article automatically — there’s no title or text control; it is purely a visual indicator.
Styling controls
In the Style tab, Height is a responsive slider (2–20px) controlling the thickness of the bar, so you can make it a hairline on desktop and slightly thicker on mobile if you want it more noticeable on smaller screens. Fill color sets the color of the progress indicator itself (defaulting to a blue, #185fa5), and Track color sets the color of the unfilled background behind it (defaulting to a translucent black, rgba(0,0,0,0.08)), which lets you build a subtle bar that barely registers until scrolled, or a high-contrast one that reinforces your brand color on every page.
When to use it
Reading Progress is built for content-heavy templates: blog post singles, knowledge-base or documentation articles, long-form landing pages, and case studies. Adding it once inside a Theme Builder single-post condition means every post on the site gets the bar automatically, without touching individual post designs. It pairs particularly well with the Table of Contents widget — the TOC gives readers a map of the article and lets them jump around, while the progress bar gives a continuous sense of overall position, and together they make a long article feel much more navigable.
Practical tips
- Use Track: Main content area on templates with heavy footers, sidebars, or long comment sections — otherwise the bar will hit 100% well before the reader actually reaches the real end of the article, or conversely never quite feel “done” if a lot of page still follows the content.
- Because the bar is fixed-position and full width, check it against any other fixed elements your theme uses (a sticky header, a cookie banner, a chat widget) so they don’t visually collide; switching Position to Bottom of screen is a quick way to avoid stacking with a sticky header at the top.
- Keep the Height small (3–6px) for a subtle, professional feel — a thicker bar can start to compete visually with your site’s actual navigation bar, especially when placed at the top.
- Since the widget listens for scroll on both window and document, it works reliably even inside themes or page builders that wrap content in their own scrollable container, so you shouldn’t need to debug “the bar isn’t moving” issues on most standard WordPress themes.