Lead: Femi
| Status | ||||
|---|---|---|---|---|
|
| Table of Contents |
|---|
Description
Scroll allows the controlled reveal of extra content which would otherwise not fit within the allocated UI area. Scroll can be used within containers of the page layout and also within individual components.
...
Types
Type | Usage |
|---|---|
Fixed Scroll | When a fixed amount of content is loaded into a container or component that is not large enough to display it all at once, a horizontal or vertical scrollbar enables the remaining content to be moved into view. |
Infinite Scroll | When a large undefined amount of content is available for a container or component that is not large enough to display it all at once, a horizontal or vertical scrollbar enables more content to be dynamically loaded into view. |
Choose the appropriate type according to the amount of content you need to display and the content area available.
...
Placement and positioning
Always offer a scrollbar if an area has scrolling content. Don't rely on auto-scrolling or on dragging, as users may not realise it's an option. The scrollbar provides a visual clue that more content is available.
Hide scrollbars entirely if all content is visible. If users see a scrollbar, they will assume there's additional content and be frustrated if they can't scroll.
Default state
Comply with the default operating system standards in order to maintain platform familiarity. All default browser scroll behaviors should be enabled by default. Operating system and browser defaults such as scroll inertia, scroll wheel support, gesture support, and any OS user customisations should all behave as factory designed.
Content
Display all important information above the fold. Users often decide whether to continue or leave based on what they can see without scrolling.
States
There are no focused or disabled states for scroll as these states are handled by the parent component.
State | Scroll |
|---|---|
Regular Vertical |  |
Hover Vertical |  |
Active Vertical |  |
Regular Horizontal |  |
Hover Horizontal |  |
Active Horizontal |  |
Interaction
| Anchor | ||||
|---|---|---|---|---|
|
Scroll interaction is governed by the device, operating system, and browser being used. The default interaction behaviours shouldn't be changed, primarily for conformance and accessibility reasons. The following are the required interaction recommendations common to all.
Input device | Discrete scroll | Continuous scroll |
|---|---|---|
Keyboard |
|
|
Mouse |
|
|
Trackpad |
|
|
Best practices
For best results, follow all the usage guidelines in this document. Further suggestions:
Avoid scrolling within scrolling. Users are often perplexed by inline scroll areas because they introduce nested scroll panes, with any inline scrollable areas being placed within a larger scrollable area. This should be avoided as it causes significant cognitive load for the user. They have to keep track of the relationship between the scroll areas because they are interrelated; for instance, the state of the page scroll area may cut off part of an inline scroll area.
Make sure the browser back button works properly. When users follow a link, and then click the Back button, they expect to return to the same spot on the original page. Traditionally, using a browser’s back button will set the scroll position back to the previous position rather than to the top of the page. However, some modern development frameworks do not offer this functionality by default. Losing their previous position forces users to scroll through content they have already seen and manually find their previous position. Try to always make sure this feature is enabled.
Avoid scroll hijacking. Applications that implement scroll hijacking take control of the scroll and override a basic function of the web browser. Scroll hijacking is best avoided because the user no longer has full control of the page scroll and thus is unable to predict its behavior. The user’s expectation of an application's scrolling interaction shouldn’t be destroyed for the sake of narrative experience.
Use sticky navigation. Long scrolling can make navigation problematic. If the user loses visibility of the navigation menu (for the container, table etc.) when they scroll down, they will have to scroll all the way back to the top to perform an action. Instead, use a sticky (persistently visible) navigation menu to make moving around the app fast and easy.
Avoid horizontal scrolling. To improve user efficiency it is best to limit scrolling to the vertical axis only.
Provide visual feedback when loading new content. When using infinite scroll, it needs to be clear to the user that content is being dynamically loaded. Use a progress indicator to show that new content will soon appear on the page.
Accessibility compliance
In general each component should be A11y complied, please follow the 3 guidelines linked below.
Focus management
The scroll component itself cannot be focused via the keyboard. Instead, it must be possible to focus the scrollable content area itself in order for the scroll component to work. Please see the Keyboard & Focus Management Guidelines to ensure that scrollable content areas are properly supported.
Assistive scrolling bindings vary with device, operating system, and browser. Nevertheless, the key bindings described in the ScrollScroll#Interaction section above should be supported as a minimum.
...
As it's recommended to use the native browser scrollbar component, screen reader support is already built in. Users are notified about scrollbars when they encounter a scrollable area with the 'overflow' property defined as 'auto' or 'scroll'. Make sure the scrollable area itself also supports screen readers where needed - see the Screen Reader Guidelines.
Design
Zeplin link | Screen thumbnail |
|---|---|
 |
Code
| Note |
|---|
Scroll is enabled by applying the appropriate CSS Overflow property value to a content area. |
...