Neglecting the scrollbar: a costly trend in UI design
I’ve noticed an alarming UI trend over the last five years or so. Apps are neglecting, misusing, or outright omitting the scrollbar from their interfaces. Notice isn’t the right word. I’ve been living this trend.
I have a physical disability that, among other things, makes it difficult for me to scroll by using a typical scroll wheel or touch surface. That means I often scroll by clicking and dragging the scrollbar.
It’s likely you haven’t thought about scrolling this way. Maybe you think of it as an old, outdated way of doing it. Or maybe you didn’t even know the scrollbar is draggable. But some people actually scroll that way! And it’s becoming more difficult than it used to be.
Benefits of the scrollbar
The scrollbar has been around for decades now and is an effective, interactive UI control. It gives you quite a bit of immediate visual feedback:
- That the area is in fact scrollable.
- About how long a given page of content is.
- How much of that content you’re viewing right now.
- Your current location on the page.
The scrollbar is a versatile control. It appears anywhere you might have a long area of content embedded in a window. That could be a single document—like a webpage—or something smaller like a menu of items. One window might have multiple embedded content areas and all of them could use a scrollbar.
It also provides some functionality:
- You can click and drag a scrollbar to move long distances in a single motion.
- You can click within the scroll track to either page up and down, or to jump to a specific point (depending on how the the scrollbar is implemented).
You might very well know what a scrollbar is and wonder why I’m rambling on about it. The point I’m trying to make is that this control is a useful, battle-tested one that is everywhere. We need to remind ourselves of that so that we know what we’re losing when we neglect it.
The cost of neglecting the scrollbar
With the proliferation of touch-based scrolling, the role of the scrollbar in modern interfaces has changed. Some might say it has evolved, but I think of it as neglect.
The scrollbar is often relegated to serving as a mere visual indicator. And in some UI patterns, like infinite scrolling, the scrollbar effectively loses all meaning or utility. As a result, they are typically styled to be thin, semitransparent, and sometimes auto-hiding. They’re optimized for being seen when the context is right (e.g., when the user is scrolling). But that comes at a cost.
The interactivity of the scrollbar is diminished when it’s made to be a visual indicator only.
- Thin scrollbars are difficult to click.
- Auto-hiding scrollbars can actively prevent scrolling if the only way to reveal them is to scroll the content.
- Non-clickable scrollbars cause confusion because some users might expect them to be clickable.
- Neglecting the interactivity of scrollbars takes away multiple methods of navigating a content area.
Example: the bad one
I want to offer a real world example of the struggle[1] I go through. One of the worst offenders in my world is the Setapp app explorer (I don’t mean any ill will here—I love Setapp).
Here’s a quick video where I demonstrate the problem.
Here’s what’s happening in the video. I’m looking at the Setapp app’s main view. I’m an onscreen keyboard user so I have my heavily modified macOS Accessibility Keyboard in the frame so you can see it.
Notice that there’s no scrollbar control visible. Hovering my mouse over the rightmost area of the screen doesn’t reveal a scrollbar. I’m able to get the scrollbar to appear by pressing the down arrow key, which scrolls a few lines and causes the scrollbar to become visible. At that point, clicking and dragging works like it normally would.
After a few seconds, the scrollbar disappears. I’m back where I started.
If it wasn’t for that workaround using the arrow key, I’d be physically unable to scroll that view. [2]
Example: the good one
One of the best scrolling experiences I have is with Visual Studio Code. As soon as you mouseover the code editor pane you can see the scrollbar. That’s a win right there—you get immediate visual feedback. You can click and drag it as you would expect. And because it’s a code editor, you get a code mini map which also functions as a scrollbar.
The best part is that the size of the scrollbar is configurable. In the video, I set the vertical scrollbar width to a nice, eminently clickable 28 pixels.
Example: the best one
One thing I adore about the web is its near infinite ability to be customized. It’s a foundational concept on the web and it enables powerful accessibility wins for users.
I use the incredible browser extension, ScrollAnywhere. It allows me to scroll webpages mobile-style by clicking and dragging anywhere on the page. This extension is a life saver for me. I want ScrollAnywhere everywhere now. It’s so good.
Considerations for developers
My pitch is simple. Scrollbars are awesome. Use them! I’ll wrap this up with a list of considerations to keep in mind when working with scrollbars, in no particular order.
- Remember that scrollbars are interactive, not just visual indicators.
- Don’t hide them without an obvious way to summon them.
- On macOS, if the user has checked the global setting for always showing scrollbars (Settings > Appearance) don’t hide them at all.
- Avoid thin scrollbars if you can help it.
- If you’re customizing the look of a scrollbar, give it enough contrast to be visible.
- Try clicking and dragging your scrollbar. If it’s difficult for you, the developer, it’s probably difficult for your users.
- Try not to hijack the scroll. Yes scrolling hijacks make for cool Awwwards websites, but they can be quite difficult to deal with.
- Don’t be afraid to make the scrollbar bigger!
- Provide a way to scroll with the keyboard (e.g., up/down arrows). It’s often the expected behavior and can be a safety net for the user in case you screw up the scrollbar for whatever reason (but please don’t screw it up).