Accessible Pagination

It is easy to think of a pager as a small interactive component, something like a slider or a menu that needs a special set of ARIA roles and a keyboard model of its own. It is not. Pagination is a set of navigation controls: a row of links or buttons that each move you to a different page of the same list. There is no role="pagination", and the WAI-ARIA Authoring Practices do not define a pagination widget, because the pieces you need already exist. A named navigation landmark, a list, ordinary links or buttons, and the aria-current state do the whole job.

Because the parts are ordinary, the mistakes are ordinary too, and they come from treating the pager as decoration rather than navigation. The number 3 becomes a styled <div> that a keyboard cannot reach. The arrows become icons with no name. The active page is a colored box that a screen reader cannot see. Each of these is a small omission, and together they turn a simple navigation control into something a large group of users cannot operate at all.

The reward for getting it right is that pagination is genuinely good for accessibility, more so than the infinite scroll it often competes with. It gives structure you can bookmark, a footer you can reach, and a way to jump to a known page, which is exactly what a keyboard or screen reader user wants when they are working through a long set of results. The rest of this guide is the handful of markup choices that deliver it. There is also an interactive pagination demo on this site that lets you hear the difference between the accessible and inaccessible versions.

Start with the server-rendered case, where each page has its own URL, because it needs no JavaScript and shows the whole structure clearly. Four decisions carry almost all of the accessibility. Wrap the controls in a <nav> with an accessible name. Put the controls in a list. Make each page a link with a descriptive name. Mark the current page with aria-current="page". Here is the whole pattern:

<nav aria-label="Pagination">
  <ul>
    <li>
      <a href="?page=1" aria-label="Go to previous page" rel="prev">
        <span aria-hidden="true">&lsaquo;</span>
        <span class="sr-only">Previous page</span>
      </a>
    </li>
    <li><a href="?page=1" aria-label="Go to page 1">1</a></li>
    <li>
      <a href="?page=2" aria-current="page" aria-label="Page 2, current page">
        2
      </a>
    </li>
    <li><a href="?page=3" aria-label="Go to page 3">3</a></li>
    <li>
      <a href="?page=3" aria-label="Go to next page" rel="next">
        <span class="sr-only">Next page</span>
        <span aria-hidden="true">&rsaquo;</span>
      </a>
    </li>
  </ul>
</nav>

Every decision is doing real work. The <nav aria-label="Pagination"> exposes a navigation landmark with a distinct name, so a screen reader user can find the pager and tell it apart from the main menu, which is also a navigation landmark. Write the label as Pagination, not Pagination navigation, because the role already contributes the word navigation and the longer label is announced as “Pagination navigation, navigation.”

The list gives the pager structure and an item count, so a screen reader can announce “list, five items” and let the user move control by control. An ordered list (<ol>) is the most honest choice, because the pages run in sequence, but an unordered list is common and widely accepted; the load-bearing parts are the landmark, the names, and the current-page state, not which list element you pick. Each page is a link that carries a descriptive name, which the next section covers in full, and the current page adds aria-current="page", covered in section three. That is a complete, accessible pager before a single line of script.

A pager without a current-page marker leaves a screen reader user unable to tell which page they are on, and it is the single most common thing missing after descriptive names. aria-currentis the state that fixes it: it marks the one control in the set that represents the user’s current position. In a pager it belongs on exactly one control, the number of the page you are viewing, and a screen reader announces that control as “current page.” Put it on more than one and it stops meaning anything.

Use the value page, not the generic true. Both are valid, but aria-current has several token values for different kinds of set, and pageis the one that means “the current page in a set of pages,” which is precisely a pager. It is the same value a breadcrumb and a site menu use to mark the current page; the accessible breadcrumbs guide covers the full set of token values, if you want the reference.

A link to the page you are on, or plain text?

The current page can be a link that carries aria-current="page" or a non-interactive element, and both are accepted. Rendering it as a link keeps the row visually and behaviorally uniform, and a link to the page you are already on simply reloads it, which is harmless. Some teams instead render the current page as a plain <span> with aria-current="page", on the reasoning that a link to the current page does nothing useful. Either is fine; the two things that are not fine are leaving the current page unmarked, and marking it only with a colored background:

<!-- As a link -->
<li><a href="?page=2" aria-current="page" aria-label="Page 2, current page">2</a></li>

<!-- As plain text (also correct) -->
<li><span aria-current="page" aria-label="Page 2, current page">2</span></li>

Do not let a background color be the only signal that a page is current, which would fail 1.4.1 Use of Color. Pair aria-current with a visible cue that does not rely on hue, such as an outline, an underline, or a bolder weight, and drive that styling from the attribute itself so the visual and programmatic states can never disagree:

/* Style the current page from the attribute, so the visual
   cue and the announced state are always in sync. */
[aria-current="page"] {
  font-weight: 700;
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

A hundred pages will not fit in a row, so a pager shows a window of numbers with the middle collapsed to an ellipsis, reading as 1 2 3 … 42 43 44 … 99 100. Two things have to be true for that to stay accessible: the ellipsis must not be read aloud, and the pages it hides must still be reachable.

The ellipsis is decoration. It marks a gap in the sequence, and a screen reader announcing “ellipsis” between page numbers adds only noise, so hide it with aria-hidden="true". Because it is not a control, it is not focusable and should never be a link or a button:

<nav aria-label="Pagination">
  <ul>
    <li><a href="?page=1" aria-label="Go to page 1">1</a></li>
    <li><a href="?page=2" aria-label="Go to page 2">2</a></li>

    <!-- Decoration only: not a control, hidden from screen readers -->
    <li aria-hidden="true">&hellip;</li>

    <li><a href="?page=42" aria-current="page" aria-label="Page 42, current page">42</a></li>
    <li><a href="?page=43" aria-label="Go to page 43">43</a></li>

    <li aria-hidden="true">&hellip;</li>

    <li><a href="?page=100" aria-label="Go to page 100">100</a></li>
  </ul>
</nav>

The more important rule is about reachability. The point of the ellipsis is that not every page number is shown, but that must never mean a page becomes unreachable. Always keep the first page, the last page, the current page, and a small window of pages on either side of the current one as real controls, so a keyboard or screen reader user can move through the set without a page being stranded behind the gap. If a user needs a page that is not in the visible window, the Next control walks them toward it, and the window slides as they go. What you must not do is drop pages so aggressively that a page in the middle has no control that reaches it.

Finally, make sure the row of numbers does not force the page to scroll horizontally at 320 pixels wide, which would fail 1.4.10 Reflow. On a narrow screen, a compact window such as Previous, 42, Nextwith a “page 42 of 100” label is often clearer than a long strip of numbers, and it keeps the pager inside the viewport.

Numbered pages are not the only way to break up a long list. Two common alternatives, a Load More button and infinite scroll, append content to the current view instead of replacing it, and they change the accessibility problem from “announce the new page” to “announce that more content arrived, and help the user find it.”

Load More: the accessible middle ground

A Load More button is the friendliest of the three patterns, because the user chooses when to load, so the moment is predictable and you own a clear place to manage focus. When the new items arrive, do two things: announce the result through a live region (“Loaded 10 more articles, 30 of 200”), and move focus to the first new item so a keyboard or screen reader user lands on the new content rather than being left at the button. The first new item needs tabindex="-1" so it can receive programmatic focus:

// After appending, move focus to the first new item.
async function handleLoadMore() {
  const firstNewIndex = items.length
  const more = await fetchMore()
  setItems(items.concat(more))
  setStatus("Loaded " + more.length + " more, " +
            (items.length + more.length) + " of " + total)

  // After the new items render, focus the first one.
  requestAnimationFrame(() => {
    itemRefs.current[firstNewIndex]?.focus()
  })
}

// The first new item is programmatically focusable:
// <li tabIndex={-1} ref={el => (itemRefs.current[i] = el)}> ... </li>

While the fetch is in flight, disable the button and change its text to “Loading…” so it cannot be pressed twice and so the state is announced. This is the same discipline as the page-change live region above, and the interactive demo shows both the Load More and infinite-scroll versions running.

Infinite scroll: use it carefully, and provide an alternative

Infinite scroll loads more content automatically as the user nears the bottom, and it carries the most accessibility risk of the three patterns. A screen reader user is not told that new items appeared unless you announce it through a live region. A keyboard user can be unable to reach the footer at all, because it keeps moving further down as new content loads. And no one can bookmark a position or return to where they were. If you adopt it anyway, announce the loading and loaded states politely, make sure a keyboard user can Tab past the feed to whatever follows it, and provide an explicit alternative, whether that is a Load More button, a “view all” link, or classic pagination. The pattern that appends articles as you scroll has its own ARIA support in role="feed", but for most lists a Load More button is simpler and kinder. For the focus and live-region details these patterns share, see the focus management guide and the 4.1.3 Status Messages reference.