Skip to content

  • VisualizationPage · Index
  • What’s newPage · Latest additions
  • Styles indexPage · Home
  • Compare stylesPage · Side by side
  • Patterns indexPage · Index
  • Articles indexPage · Index
  • Folio design systemPage · House system
  • Folio FoundationsPage · House system
  • Folio ComponentsPage · House system
  • Folio PatternsPage · House system
  • Folio MotionPage · House system
  • Folio ExamplesPage · House system
  • Folio ButtonsPage · Component
  • Folio Text fieldsPage · Component
  • Folio SelectPage · Component
  • Folio Checkboxes & switchesPage · Component
  • Folio Radio groupsPage · Component
  • Folio TabsPage · Component
  • Folio MenusPage · Component
  • Folio DialogsPage · Component
  • Folio TooltipsPage · Component
  • Folio Breadcrumbs & paginationPage · Component
  • Folio CardsPage · Component
  • Folio Badges & avatarsPage · Component
  • Folio Data tablesPage · Component
  • Folio Progress & loadingPage · Component
  • Folio FeedbackPage · Component
  • Folio Empty statesPage · Component
  • Folio MediaPage · Component
← UI patterns

Pagination

Splitting a long list or result set into discrete, numbered pages, so people can sense the scale, jump anywhere, and return to a known spot.

Showing 101 to 120 of 478

A full numbered pager: a nav landmark with Previous, Next, page links, an ellipsis for the skipped run, and the current page marked with aria-current. Click any number to move.
The responsive fallback: when the number strip will not fit, it collapses to Previous, the current page count, and Next. The position and both step controls survive the squeeze.

Behavior

Keyboard

Tab / Shift+Tab
Move focus through the pager controls in order: previous, the page links, then next. Each is a standard link, so the keyboard model is the native link model, not a custom widget.
Enter
Activates the focused page link, previous, or next, navigating to that page exactly as activating any link does.
Parts

Navigation landmark

A <nav> element with an accessible name (aria-label="Pagination") that wraps the whole control. The landmark lets assistive-technology users jump straight to the pager, and the name distinguishes it from other navigation on the page. There is no role=pagination; the nav landmark plus links is the pattern.

Numbered page links

One real anchor per page, each pointing at that page's URL. Real links are crawlable, openable in a new tab, and restorable on refresh, which buttons in a single-page app are not unless wired carefully. The links carry the heart of the pattern: a tappable target for every page in the visible window.

Previous / Next controls

Controls at the ends for stepping one page at a time, each with an accessible name ("Previous page", "Next page") since an arrow glyph alone is not a label. Previous is omitted or disabled on the first page and Next on the last, so the control never points past the ends of the set.

Current-page indicator

The page the user is on, styled distinctly and marked with aria-current="page" so a screen reader announces it as the current item in the set. Only one element in the pager carries aria-current. This is the single attribute that does the real accessibility work here.

Ellipsis and range summary

When there are too many pages to list, an ellipsis stands in for the omitted run, e.g. 1 … 4 5 6 … 100. An optional "showing X to Y of Z" summary and a per-page count give a sense of total scale and exactly which slice is on screen.

States

Current page

The active page is visually distinct (filled or boxed) and carries aria-current="page". It is commonly rendered as static text rather than a link to itself, since a link to the page you are already on does nothing. Exactly one element in the pager is marked current at a time.

Disabled ends

On the first page there is no previous; on the last page there is no next. Designs either omit those controls entirely (GOV.UK's approach) or render them visibly disabled. If disabled, prefer removing them from the tab order or replacing the link with non-interactive text, since a disabled-looking link still reachable by keyboard misleads users.

Hover and focus

Every page link, plus previous and next, needs a clear hover and a visible focus indicator, because the pager is keyboard-operated. Targets should be comfortably sized and spaced; cramped, tiny number cells are hard to tap on touch and to hit with an imprecise pointer.

Responsive collapse

On narrow screens the full number strip rarely fits, so it collapses toward previous and next plus the current page (for example "Previous Page 3 of 14 Next"), trimming or dropping the inner numbers. The current page and a way to step in both directions are the parts that must survive the squeeze.

Loading and history

With server-rendered links a click is a navigation: the URL changes and the new page loads. In a single-page app, paging should still update the URL (history.pushState) and manage focus and a loading state, so the back button returns to the prior page and a refresh restores the same slice rather than resetting to page one.

References

GOV.UK pagination control showing a Previous link, page numbers 1 with an ellipsis then 6 7 8 then an ellipsis and 42, and a Next link, with one page number highlighted as current.
GOV.UK pagination componentGOV.UK Design System
MDN documentation page for the aria-current attribute, showing the table of values including page, step, location, date, and time.
aria-current attribute referenceMDN Web Docs

Use it

Figma
A pagination component with state variants
  1. Build a Page Number component with a State property: Default, Hover, Current. Give Current a filled background using the page accent and high-contrast text.
  2. Make the cells an Auto Layout row with even gaps and a comfortable minimum size (around 40 by 40), so numbers are not cramped and stay tappable.
  3. Add Previous and Next components at the ends with an arrow plus a label, and a Disabled variant for the ends of the range.
  4. Drop in an Ellipsis cell as a separate component to stand in for skipped pages, so a long range reads as 1 … 4 5 6 … 100.

Expose the current-cell fill as a variable so a themed page can recolor it, and annotate that the current cell maps to aria-current="page" in the build.

Responsive previous/next fallback
  1. Make a second variant of the pager that shows only Previous, a "Page X of Y" label, and Next.
  2. Use Figma variants or a max-width rule so the full number strip swaps to this compact form on narrow frames.
  3. Keep the current-page count and both step controls; drop the inner numbers, since those are what overflow first.
  4. Annotate that the compact form is the same nav landmark with the same accessible names, just fewer visible links.

Test the layout at 320px wide; if the numbers still overflow, the breakpoint to the compact form is set too narrow.

Document paging vs Load more vs infinite scroll
  1. Lay out three labeled mini-mockups side by side: numbered pagination, a Load more button, and an infinite-scroll feed.
  2. Caption pagination as best for goal-directed search and tables: scale, jump-to-page, return-to-item, crawlable URLs.
  3. Caption Load more as the middle ground that keeps the footer reachable and gives the user control over loading.
  4. Caption infinite scroll as exploratory feeds only, and flag its footer and return-to-item costs.

Keep this trio in the team library so the loading-model decision is made once with the tradeoffs visible, not re-argued per feature.

Accessibility

There is no dedicated WAI-ARIA pattern for pagination. You build it from a nav landmark with an accessible name, real anchor links (one per page), aria-current="page" on the current link, and accessible names on previous and next. Keep links as links (not disabled buttons), give every control a visible focus style and a comfortable target size, and let the keyboard tab through the controls in reading order. The current-page marker and accessible names carry almost all of the accessibility weight.

  1. Keep links as links: avoid disabled links at the ends, since a disabled style is invisible to keyboard and screen-reader users; omit the control or use non-interactive text instead.
  2. Give every control a visible focus indicator and a comfortable target size; do not pack page numbers into tiny cramped cells.
  3. Update the page <title> (and ideally an on-page summary) to reflect the page number, e.g. "Search results (page 2 of 4)", so the current position is announced.
  4. Prefer visible text labels over visually-hidden-only ones for voice-control and translation parity; if you add "page" context to each link, test whether it helps before hiding it.
  5. When choosing infinite scroll instead, provide a keyboard-reachable Load more control and keep the footer accessible, since pure infinite scroll strands the footer and breaks return-to-item.
Research notes & sources

No dedicated APG pattern: built from a nav landmark (aria-label), real links, and aria-current=page on the active page

  1. PaginationGOV.UK Design System
  2. Feedback on a Pagination Pattern
  3. ARIA: aria-current attributeMDN Web Docs
  4. Infinite Scrolling: When to Use It, When to Avoid ItNielsen Norman Group
  5. Testing Pagination Against Infinite Scrolling and 'Load More' ButtonsBaymard Institute
  6. Infinite Scrolling, Pagination Or 'Load More' Buttons? Usability Findings In eCommerceSmashing Magazine
  7. PaginationShopify Polaris
  8. Accessible PaginationAccessibility Matters
  9. Google says it doesn't use rel=prev/next for paginationYoast