Hiding important content, like navigation, from users is generally a bad idea. Especially if they need to use more time to get to it. Clicking a single button to expand navigation is probably not so difficult and time consuming (if experience is accessible, with states and roles being announced to screen readers and visual affordances), but having to scroll horizontally to reach items in navigation can be quite difficult and time consuming for multiple groups of people.
Based on current screens we need scrolling. Limited screens and their dynamic areas require us to scroll if content is too big for them anyway. We are quite used of scrolling, from the spreading of responsive design this is often a single direction (vertical).
Scrolling is required even more when we zoom in. Unfortunately often in both directions. But having a webpage or app that is generally only scrolled vertically with parts that require horizontal scrolling is not optimal and needs to be carefully planned for.
Web Content Accessibility Guidelines (WCAG) try to guide us with Success criterion 1.4.10 Reflow (AA, opens in new window), but it basically applies only for the whole screen (with allowed exceptions, like tables). Other WCAG guidelines don’t really consider horizontal scrolling of regions on the page (or app). Some could argue that WCAG Success criterion 2.5.7 Dragging Movements (AA, opens in new window) could be relevant for such regions, but it is not as scrolling is not dragging, but something our browsers provide for us out of the box (so not the authors responsibility).
We also need to consider that sometimes users don’t really understand that there is a scrollable region. Sometimes their browsers hide the visual affordances, sometimes they use another device that is different from the ones they are using normally and so on.
There is an older article from NNgroup on issues with horizontal scrolling on desktops (opens in new window) that I also recommend.
How users scroll besides mouse and touch?
Besides mouse and touch, how do users actually scroll? I think that this is an important question for all features, not only scrolling.
Knowing and understanding how different people interact differently with web and mobile apps is crucial if we want to make our products accessible, especially when WCAG doesn’t define what we need to do.
When we have no guidelines we need even more awareness and knowledge.
So let’s take some common other user interactions that we need to consider:
Keyboard (and keyboard like device) users
Keyboard users can “scroll” with arrows, but we need to make sure they can get to the scrollable area in the first place. Scrollable area must get focused and we must enable this in the code (some browsers need this, some not, so best to just add tabindex=”0″ to the scrollable area). And while at it also add it’s role and name please.
If scrollable area uses interactive elements, then scrolling horizontally happens “automatically” when keyboard users use the tab key to navigate from element to element.
We can establish that keyboard users don’t have issues scrolling, but sometimes developers need to apply extra code for such areas.
Screen reader users
We could say that scrolling is not relevant for users that don’t see the screen, but actually it is. And some screen reader users also see the screen, so it’s crucial that screen reader navigation scrolls when needed. On mobile phones it’s quite usual to scroll with gestures, to discover interesting elements and content, and when using screen readers multiple possibilities of navigation the screen reader cursor movement also scrolls the screen (moves to the element and scrolls to it).
We can establish that scrolling is not an issue for screen-reader users, it just works, both horizontally and vertically. We need to be a bit careful with the Document Object Model (DOM) order, but that is important for all cases and users.
Voice control users
To my knowledge, based on testing with all available assistive technologies I have at my hands (iPhone, Android phone, PC, MAC) I can just say that horizontal scrolling of scrollable regions on a webpage or app can be quite challenging for voice control users, especially if they are new to that type of assistive technology.
Dragon naturally speaking, Voice Access, Voice Control and other assistive technologies that allows us to use the interfaces with voice alone all support scrolling, but sometimes it’s a bit complicated, especially for less known components (like horizontal scrolling regions are).
Scrolling the whole page or view vertically is simple, scrolling the whole page or view horizontally is also quite simple, but scrolling inside limited regions needs most attention and cognitive load is quite high, provided we even know how to do it. This also takes quite a lot of time. I must just say that because of this experience I will not recommend using horizontally scrolling regions for vital things like navigation.
What to consider when we absolutely want horizontally scrollable regions
If we want to use regions with horizontal scrolling we should be careful to consider some best practices and make lives of our users a bit more simple.
Some things come to my mind:
- Always show scrollbars (don’t hide them on purpose) – the affordance should be there or people will potentially miss it.
- Make scrollbars large enough (at least don’t make them smaller than browsers default).
- I advise against changing colors of the scrollbars as you may risk contrast issues (again, browsers default should be respected otherwise we are responsible for the accessibility of scrollbars and need to make sure contrasts and sizing is conformant).
- Use tabindex=”0″ on the scrollable area if elements inside are not interactive (this is required by some browsers and when we make an region focusable we also need to define it’s accessibility name and role).
- Consider the options that makes it possible for users to switch to a layout that does not require the user to scroll (for example allow overflow of items, so that we don’t need horizontal scrolling).
- And for voice control users it’s perhaps best to add buttons that can scroll the content (like next and previous set of items, as a minimum).
There are probably some other things that needs considering, but if we at least consider these we may start with user testing that will potentially reveal other things. Remember to test with multiple assistive technologies, but don’t assume how everything is being used by users that depend on them. That’s why we need to verify our product accessibility with people with disabilities if we want to be more confident.
Additional resources
- I like to check WCAG techniques and I’ve found WCAG Technique G206 (opens in new window) that mentions the possibility to provide options within the page or app to switch to a layout that does not require the user to scroll horizontally (although that one is more suitable for lines of text).
- Accessibility Conformance Testing Rules has an article about proposed ACT rule for scrollable content (opens in new window) that can be reached with sequential focus navigation.
- I also liked Kevin Yank’s article on horizontal scrolling (opens in new window) with lots of technical details and other references.
