Short description

We use pagination to divide data into several pages and let the user navigate between them. By doing this we prevent pages from becoming too long and overwhelming. Pagination is similar to physical books with page numbers.

When and how to use it

Use it when you have a lot of data that can't be easily presented on one screen. Divide the data automatically with an algorithm that adjusts the data to the amount of space it is given.

The placement of the component varies but is very important. The component should be placed at the top and the bottom of the data set, if the amount of data is so long that the user can't see the top and the bottom at the same time. By doing so you eliminate the unnecessary activity of scrolling up and down only to navigate between pages. If the user can see the top and the bottom at the same time it is enough with placing the component at the bottom or the top.

Behaviour

The pagination component is transparent so that it can be discretely placed on both a grey or white background. The first and last pages are always visible in the component. This gives the user an understanding of the total amount of data. The page that the user is currently viewing is identified by a dark grey square that is not clickable. All of the other squares are transparent and clickable. If the user hovers a square a discrete shadow appears around the square. There are two squares with arrows, they help the user to navigate to the next or the previous page.

It can be a good idea to combine pagination with filtering and the possibility to search within the data set. If the user needs to be able to jump straight to a page there is an optional component that is placed on the right-hand side that allows the user to enter a page number and go straight there.

Placement

Default placement is under the data-set to the left. However, place it where it makes sense (left, centered, right) related to other components and layout of content. If the data-set is so long that user has to scroll to see it, place a pagination both at the bottom and the top, or perhaps sticky to the bottom.

Do's and don'ts

Do

• Use pagination when the data set is so big that it can overwhelm the user.
• Present the component with a lot of page numbers if you have the space for it.
• If possible, offer the user the possibility to filter or search within the data set.

Don't

• Avoid placing the component at only the bottom or the top if the user has to scroll to see the component.
• Don't make the data sets on each page to small

General considerations

There exists a fundamental difference between buttons and links. Semantically, buttons should be used for submitting forms or for interactive components that stay on the same page. In comparison, links should be used as anchors or when the destination is another page.

• If used within a single-page application, ensure that clickable elements are coded as buttons.
• If the clickable elements generate new pages, ensure they are coded as links. There exists a fundamental difference between buttons and links. Semantically, buttons should be used for submitting forms or for interactive components that stay on the same page. In comparison, links should be used as anchors or when the destination is another page.
• The previous button/link must not be focusable when the first page in the pagination component is selected.
  • If the user has entered the first page through the previous button, the focus is then shifted to the first page button in the pagination.
• The next button/link must not be focusable when the last page in the pagination component is selected.
  • If the user has entered the last page through the "next" button, the focus is then shifted to the last page button in the pagination.

Keyboard interactions

• The focus must move to each active control within the pagination component and have a visible indicator.
• It’s important to note that buttons can be triggered via the keyboard with the Enter or the space bar, while links are triggered only with the Enter keystroke. These keystroke behaviours are known and expected by keyboard and screen reader users and must be kept.

Screen Reader interactions

For screen reader users to understand the pagination functionalities we use ARIA regions, properties, or states as follows

• Ensure the pagination region is appropriately identified. Group the entire component with a nav element and with an aria-label attribute (e.g. <nav aria-label=”Pagination”>).
• Use a list structure with appropriate ARIA properties. Add the attributes aria-setsize to the list and aria-posinset to the list items.
• Ensure the page numbers have labeling identifying what the numbers refer to
  (i.e., <a href=”...” aria-label=”Page 1”>1</a>).
• Add aria-current="page" or "true" to the current page number to explicitly indicate that it is active.
• Ensure the previous, and next buttons/links have appropriate labels with an alt text or an aria-label attribute. The previous and next buttons/links can be included within the numbers list, but it is optional.
• If an ellipsis is used between numbered pages, it must have an appropriate label.
• If the content is changed dynamically without generating a new page, this must be announced to the screen reader programmatically.

Review

Result from the latest accessibility review of the component (Chlorophyl): 2024-07-30

• Contrast: ok
• Colour-blindness: ok
• Code + aria: ok
• Touch + keyboard: ok
• Dark-mode: ok
• Focus: ok
• Reader: ok

• Details: Specification in Figma
• Instruction: How to access Figma