Accessible Pagination: Why Your 'Page 1, 2, 3' Buttons Might Be Locking People Out

Pagination is the row of numbered links — “Previous 1 2 3 … 12 Next” — that sits at the bottom of a blog archive, a product listing, or a page of search results. It is one of the most common patterns on the web, and one of the most quietly broken. Because it looks trivial, almost nobody tests it. Yet for someone using a screen reader or navigating only with a keyboard, a badly built pagination row can mean not knowing which page they are on, not being able to reach the next page at all, or landing back at the top of the page with no idea that anything changed.

This guide explains, in plain language, why pagination fails for people with disabilities, what a good version does differently, and how to check yours — even if you have never opened a line of code. If you run a shop with dozens of products, a blog with an archive, or any site with search results, this affects you.

Why pagination matters more than it looks

When a sighted mouse user reaches the bottom of a listing, they see the numbers, understand instantly which one is “current” because it is highlighted, and click the next one. All of that visual context — the highlight, the position, the fact that the page reloaded with new content — is delivered through sight and a mouse.

Take those two things away and the pattern can collapse. A blind person hears whatever their screen reader announces, and nothing more. A person with a motor disability, or anyone using a keyboard because a mouse is painful or impossible, has to reach every control with the Tab key and activate it with Enter or Space. If your pagination was built only for the mouse-and-eyes case, these users hit walls that are invisible to you.

And this is not a fringe concern. Roughly one in four adults lives with a disability. Many of them shop, read, and research online every day. If your product catalog is spread across ten paginated pages and a screen reader user can only reach page one, you have effectively hidden ninety percent of your inventory from them.

The five most common pagination failures

1. No indication of the current page

The single most frequent failure. Visually, the current page number is shown with a colored background or bold text. But color and weight are purely visual — a screen reader announces “3, link” whether or not page 3 is the one you are on. The user has no way to know where they are in the sequence.

The fix is a small, standardized attribute called aria-current="page". When it is added to the current page’s link, screen readers announce something like “3, current page.” That one addition turns a disorienting list of numbers into a clear map. It is invisible to sighted users and changes nothing about how the page looks — it only adds meaning for assistive technology.

2. Pagination that a keyboard can’t reach or operate

Many “modern” pagination widgets are built with clickable <div> or <span> elements dressed up to look like buttons. A real link (<a>) or button gets keyboard focus and responds to Enter automatically. A styled <div> does not. So a keyboard user pressing Tab sails right past the page numbers, or lands on them but finds that pressing Enter does nothing.

Every page control — numbers, Previous, Next, First, Last — must be a genuine link or button that you can reach with Tab and activate with Enter (and, for buttons, Space). If you can’t Tab to your own pagination and press Enter to move pages, neither can anyone who relies on the keyboard.

3. No visible focus indicator

Related to the above: keyboard users track their position on the page by the focus ring — the outline that shows which control is currently selected. A distressing number of sites remove that outline for looks, using a line of CSS that hides it globally. Now the keyboard user is Tabbing through invisible controls, guessing where they are.

Your pagination links must show a clearly visible focus indicator when Tabbed to. This maps to WCAG success criterion 2.4.7 (Focus Visible), and WCAG 2.2 added 2.4.11 (Focus Not Obscured), which requires that the focused control is not hidden behind sticky headers or footers. Never remove focus outlines without replacing them with something equally visible.

4. Silence after the page changes

On many sites, clicking “Next” loads new content without a full page reload — the products swap out in place. Sighted users see the change. But if nothing moves keyboard focus and nothing is announced, a screen reader user hears silence. They activated “Next,” and as far as their ears can tell, nothing happened. Did it work? Are these new products or the same ones? They can’t tell.

There are two complementary fixes. First, move keyboard focus to a sensible place after the change — typically the heading of the new results, or the top of the results region — so the user is carried to the fresh content instead of being stranded at the bottom. Second, announce the change with a short, polite live-region message such as “Showing results 21 to 40 of 240.” A live region is a small piece of text that screen readers read aloud automatically when it updates, without the user having to go looking for it.

5. Tiny targets and low-contrast numbers

Page numbers are often cramped into small, closely spaced boxes with thin, pale text. Two problems follow. People with low vision or color vision differences may not be able to read the numbers, especially the muted “current” or “disabled” states — text needs a contrast ratio of at least 4.5:1 against its background under WCAG 2.1 AA (criterion 1.4.3). And people with tremors or imprecise pointing struggle to hit small, tightly packed targets; WCAG 2.2’s criterion 2.5.8 (Target Size) calls for interactive targets of at least 24 by 24 CSS pixels, with spacing counted as an alternative.

What good, accessible pagination does

Pull the fixes together and a well-built pagination pattern looks like this:

  • It lives in a labeled landmark. The whole set of controls is wrapped in a navigation region — a <nav> element with a label such as aria-label="Blog archive pages". This lets screen reader users jump straight to it and tells them what it navigates. If you have more than one <nav> on the page, each needs a distinct label.
  • The current page is marked with aria-current="page", so it is announced as the current page, not just another number.
  • Previous and Next have real, descriptive names. An arrow icon alone announces nothing useful. The control needs accessible text like “Previous page” and “Next page” — either visible text or a screen-reader-only label behind the icon.
  • Disabled controls are genuinely disabled, not just faded. On page one, “Previous” should not be a dead link that traps focus and does nothing. Either remove it or mark it as disabled so assistive technology skips it and announces it as unavailable.
  • Every control is keyboard-operable with a visible focus ring.
  • After a page change, focus moves to the new content and a live region announces the new range.
  • Numbers meet contrast and target-size minimums.

None of this changes the visual design your customers see. It adds a layer of meaning and operability underneath it, for the people who need it.

Pagination versus “Load more” and infinite scroll

You may be wondering whether you should ditch numbered pages entirely for a “Load more” button or infinite scroll. From an accessibility standpoint, numbered pagination is often the safer default. It gives users a finite, predictable structure, a way to jump to a known page, and a natural stopping point. Infinite scroll, done carelessly, can trap keyboard users who can never reach the footer, and can overwhelm screen reader users with content that never ends. A plain “Load more” button is usually more accessible than true infinite scroll, but it still needs the same focus-management and announcement care described above. Whichever you choose, the principle is identical: never let content change without telling assistive-technology users that it changed.

How to test your pagination in five minutes

You do not need developer tools for a first pass. Try these three checks on any paginated page of your site:

  1. The keyboard-only test. Put your mouse away. Press Tab repeatedly until you reach the page numbers. Can you see a clear outline moving onto each one? Can you press Enter to go to the next page? If Tab skips the numbers, or the outline vanishes, or Enter does nothing, you have a problem.
  2. The zoom test. Zoom your browser to 200% (Ctrl or Cmd and the plus key). Are the page numbers still readable and still clickable without overlapping? Can you still tell which page you’re on?
  3. The screen reader test. Turn on the screen reader already built into your device — VoiceOver on Mac and iPhone, Narrator on Windows, TalkBack on Android. Navigate to the pagination and listen. Does it tell you which page is current? When you activate “Next,” does it announce the new results, or fall silent?

If any of these fail, you have found exactly the barrier your disabled visitors are hitting — and a specific, fixable thing to hand to whoever maintains your site.

The bottom line

Pagination feels like a solved problem because it is visually familiar. But familiarity is a sighted-mouse-user’s luxury. For everyone else, the difference between accessible and inaccessible pagination is the difference between browsing your whole catalog and being stuck on page one. The fixes are small, standardized, and invisible to your existing design: a aria-current attribute, real links and buttons, a visible focus ring, a short spoken announcement after each change, and readable, tappable numbers. Get those right and you have quietly opened the rest of your site to a quarter of your potential audience.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.