# Pagination or infinite scroll?

[Website version](https://patterns.alexanderclaes.com/patterns/pagination/)

Updated 30 October 2026

Choose based on whether users need a place they can return to or a continuous feed.

## Sources take different approaches

GOV.UK recommends avoiding infinite scrolling because it causes keyboard-access problems. W3C APG describes a feed interaction contract that supports automatic loading with assistive technology. This guide already favors pagination and notes the additional work required for a continuous feed.

**Preferred starting point:** [GOV.UK · Pagination](https://design-system.service.gov.uk/components/pagination/). Start with GOV.UK for result-page navigation. Consider the APG feed approach only when continuous browsing fits the task and its keyboard, reading and position-restoration behavior can be supported.

Compare: [W3C APG · Feed pattern](https://www.w3.org/WAI/ARIA/apg/patterns/feed/). [How we choose sources](https://patterns.alexanderclaes.com/about/#sources).

## Recommendation

Prefer pagination for focused searches and revisiting result pages. Split the list only when it improves usability or performance.

## Problem

A long result list is slow to load or hard to navigate.

## Use pagination when

- Users need result pages they can link to, share, or revisit.
- Loading the whole collection is too slow, or most users need only the first few pages.

## Pagination and scrolling mistakes to avoid

- Splitting a manageable list just because it extends beyond one screen.
- Using infinite scroll by default, or making the footer and earlier results hard to reach.
- Assuming page numbers alone preserve a position when the query, ordering, or underlying results change.

## Example

[View the example on the website](https://patterns.alexanderclaes.com/patterns/pagination/#example).

## Implementation

1. Use real links for result pages with URLs. Preserve the query, sort, and filters; apply sorting and filtering to the whole result set and return to the first page when they change.
2. Label the pagination navigation, give numbered links names such as Page 2, and mark the current page visually and with aria-current="page".
3. Include the page number in the document title. Keep the controls manageable on small screens and omit pagination when there is only one page.
4. For Load more, provide a logical route into the newly added items. Moving focus to the first new item can help when they are inserted before the button; keeping focus on the button is not a universal rule.
5. Expose dynamic loading or result-count messages to assistive technology, for example with role="status". Announce a concise summary, not the entire result list, and restore loaded content and position on return.

## Tradeoffs

Pagination interrupts scanning but provides page destinations. Infinite scroll supports continuous browsing but needs careful keyboard access, loading, and recovery behavior. Load more gives users control over when the list grows. All three need deliberate state restoration.

## Verification

Can users open a result, go back, and resume at the same place? With a keyboard and screen reader, can they reach new items, identify their position, and leave the results?

## References

- [GOV.UK · Pagination](https://design-system.service.gov.uk/components/pagination/)
- [GitHub Primer · Focus management](https://primer.style/accessibility/design-guidance/focus-management/)
- [W3C WCAG 2.2 · Status messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html)
- [W3C APG · Feed pattern](https://www.w3.org/WAI/ARIA/apg/patterns/feed/)

## Related patterns

- [Search, filters, or both?](https://patterns.alexanderclaes.com/patterns/search-or-filters.md)
- [Table or cards?](https://patterns.alexanderclaes.com/patterns/tables-or-cards.md)
