Blog October 23, 2026 · 14 min read

Pagination Accessibility: Markup, Keyboard and Testing

Specialist testing paginated results with keyboard navigation

Accessible pagination is a named navigation region that holds a list of real links, marks the current page with aria-current="page", works from the keyboard with a visible focus indicator, and uses controls large enough to tap. If your pager is a row of tiny numbers inside anonymous div elements, it probably fails at least one of those tests. The good news is that the fixes are small, permanent and easy to verify.

This guide walks through the markup, the keyboard behavior, target size, the ellipsis problem, and what to do when someone asks for infinite scroll. It also covers what automated scanning can and cannot tell you, so you can document your work honestly.

AccessWiser

accesswiser.com

Find and Fix Pagination Barriers

AccessWiser scans for WCAG 2.2 AA issues, links findings to affected elements, and provides plain-language guidance for fixing them in your code.

Explore accessibility scanning

TL;DR

Wrap pagination in a nav element with a unique accessible name, use a list of links inside it, and put aria-current="page" on the current page.
Every control must work with Tab and Enter, show a visible focus state, and never trap the keyboard.
Make page links and Previous/Next controls at least 44 by 44 CSS pixels, and label them with words, not just digits or arrows.
If you use infinite scroll, offer a “Load more” button or real paging so keyboard users can reach the footer and return to where they were.
Automated scans catch markup problems, but keyboard and screen reader checks are still needed. Keep dated records of both.

Why pagination deserves its own accessibility pass
The markup: a named nav, a list, real links
Keyboard operation: where visually perfect pagers fail
Target size and spacing
Handling the ellipsis and long page ranges
Pagination, infinite scroll and “Load more”
Is pagination a frontend or backend job?
Frameworks, tables and plugins
What automated scanning can and cannot tell you
A pagination checklist you can copy
Our perspective: fix the code, then keep the proof
Check your pagination across the whole site
FAQ
Sources

Why pagination deserves its own accessibility pass

Pagination looks simple, so it often escapes review. Yet it is the main way visitors move through product listings, blog archives, search results, directories and appointment lists. When it breaks, people lose access to everything past page one.

W3C describes navigation as doing two jobs: helping users determine where they are and go somewhere else. A pager that shows numbers but does not announce the current page fails the first job. A pager with unlabeled arrow icons fails the second.

The people affected are broader than screen reader users. Keyboard-only users need predictable focus. People with low vision need visible state and contrast. People with motor disabilities, and anyone on a phone, need targets they can hit. People with cognitive disabilities benefit from consistent, clearly named controls. W3C’s page structure guidance makes the same point about regions: structure helps far more people than assistive technology users alone. That matches how we think about accessibility at AccessWiser: fix the structure once and everyone benefits.

The markup: a named nav, a list, real links

The W3C Design System pagination component is a good reference pattern. It uses a nav element named by a visually hidden heading, a ul with li items, and aria-current="page" on the current page. Here is a simplified version:

<nav aria-label="Pagination">
  <ul>
    <li><a href="/blog/?page=2">Previous<span class="visually-hidden"> page</span></a></li>
    <li><a href="/blog/?page=1" aria-label="Page 1">1</a></li>
    <li><a href="/blog/?page=2" aria-label="Page 2">2</a></li>
    <li><a href="/blog/?page=3" aria-label="Page 3, current page" aria-current="page">3</a></li>
    <li><a href="/blog/?page=4" aria-label="Page 4">4</a></li>
    <li><a href="/blog/?page=4">Next<span class="visually-hidden"> page</span></a></li>
  </ul>
</nav>

A few choices here are worth explaining.

Give the nav a unique name

Most pages already have a main menu that is also a navigation landmark. If the pager has no name, a screen reader user hears two unlabeled navigation regions and cannot tell them apart. The W3C example names its region with aria-labelledby pointing to a hidden heading. An aria-label works too. Keep the name short and specific, such as “Pagination” or “Search results pages” when a page has more than one pager. Because the role already says “navigation,” repeating that word in the label is redundant.

Use links when the URL changes

If clicking page 3 loads a new address, it is a link. Use a with an href. Links give you right-click, open in a new tab, bookmarking, middle-click and sensible Back button behavior for free. Reserve button for controls that change content in place without changing location, and then manage focus and announcements yourself.

Mark the current page

Put aria-current="page" on exactly one item. Pair it with a visual indicator that does not rely on color alone, for example a border, bold weight or underline in addition to a fill. Sighted users and screen reader users should get the same information.

Name controls with words

A link that announces only “3” tells a screen reader user little. Add context such as “Page 3” through aria-label or visually hidden text. Previous and Next should say so in text, not rely on < and > glyphs or icon-only buttons. If you use aria-label on a link whose visible text is a number, make sure the label starts with or contains the visible text so voice control users can still say what they see.

Keyboard operation: where visually perfect pagers fail

A pager can look flawless and still fail a keyboard test. The U.S. Access Board’s ICT Baseline requires that all functionality be operable through a keyboard interface, with no keyboard trap. In practice that maps to WCAG 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order and 2.4.7 Focus Visible.

Run this quick check on every pager you ship:

Press Tab from the content above the pager. Focus should arrive on the first control in a logical order.
Tab through each control. Focus should move left to right (or the reading order of your language) and never jump unexpectedly.
Press Enter on a page link. It should navigate or update the results.
Look at the focus indicator on every control, including the disabled-looking ones. It should be clearly visible against the background.
Tab past the last control. You should be able to leave the component and reach the footer or next region.

If you want a deeper developer walkthrough, our guide to testing and fixing keyboard accessibility covers focus order, traps and visible focus in seven steps.

What happens to focus after a page change

When pagination loads new content without a full page reload, focus can be left on a control that has vanished or been replaced. Keyboard and screen reader users then start from the top of the document with no idea anything changed. A sensible pattern is to move focus to the results heading or the top of the updated list, and to announce the new state (for example, “Page 3 of 12, 10 results”) in a polite live region. Full page loads reset focus naturally, which is one more reason to prefer real links.

Focus and announcements after pagination update

Target size and spacing

Small numbered links packed tightly together are hard to hit with a thumb, a tremor or a trackpad. W3C’s technique for pagination-style targets demonstrates links with a minimum inline and block size of 44 CSS pixels, with space between them. That technique relates to the Enhanced target size criterion (2.5.5), so treat it as a strong, practical goal rather than the only way to meet the baseline.

A starter CSS pattern:

.pagination a {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-inline-size: 44px;
  min-block-size: 44px;
  margin-inline: 4px;
}
.pagination a:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 2px;
}

On narrow screens, do not shrink the targets to fit more numbers. Show fewer: Previous, the current page, Next, and perhaps the first and last. That brings us to the ellipsis.

Handling the ellipsis and long page ranges

With 40 pages, you cannot show every number. Designers use an ellipsis (1 2 3 … 38 39 40). Three rules keep it accessible:

Make it non-interactive text. An ellipsis is not a control. Do not give it a link or tab stop.
Hide it from assistive technology or give it a clear meaning. Many teams set aria-hidden="true" on the ellipsis so it is not read as “dot dot dot.” The pager still works because the surrounding links carry their own names.
Keep a consistent pattern. WCAG’s Consistent Navigation criterion, which the Access Board baseline groups with repeated content, asks that navigation repeated across pages appear in the same relative order. A pager that rearranges itself between pages is harder to learn.

Also consider adding “Page 3 of 12” as plain text near the pager. It gives everyone orientation, including people who skim past the control itself.

Pagination, infinite scroll and “Load more”

Many site owners ask whether they can swap pagination for infinite scroll. You can, but it creates problems that paging does not. Content that loads automatically as you scroll moves the footer out of reach, makes it hard for keyboard users to get past the list, can lose the user’s place after Back, and gives screen reader users no clear signal that new items appeared.

If you need continuous loading, consider these options in order of safety:

Pattern	Keyboard	Screen reader	Back button and bookmarks	Footer access
Numbered pagination with links	Strong	Strong when named and marked	Strong	Strong
“Load more” button	Good if focus is managed	Good with a status announcement	Needs URL state	Good
Automatic infinite scroll	Weak	Weak without extra work	Often lost	Often unreachable

If you choose a “Load more” button, do three things. Keep it a real button with clear text. After new items load, leave focus on the button or move it to the first new item, and announce the result count in a live region. Update the URL (for example with a page parameter) so people can return to or share their position. Then add search, filters or categories so visitors are never forced to scroll through everything.

That last point lines up with WCAG’s Multiple Ways criterion. The Access Board baseline notes that more than one way should be available to locate a page within a set of pages, with exceptions for processes. Pagination is one way. Search, categories and menus are others. Pagination alone should not be the only path to your content.

Is pagination a frontend or backend job?

Both. The backend or data layer decides which records belong on each page and supplies the page state. The frontend renders the controls, labels, focus behavior, current-page state and navigation. Accessibility failures almost always happen in the frontend, even when the pagination data is correct. So when you audit, test the rendered output in a browser, not the API response.

Frameworks, tables and plugins

Pagination often comes from a plugin or component library: a WordPress theme, a Shopify collection template, a data table library or a React component. These are the places where we see the same problems repeat: unnamed navigation regions, missing current-page state, controls built from div or span with click handlers, and icon-only arrows with no text alternative.

Before adopting any component, test it against the checks in this article. If it fails, you have three choices: configure it, wrap it, or replace it.

Data tables with built-in pagination deserve extra attention. The pager sits outside the table in the DOM, so a screen reader user may change pages and hear nothing. Announce the new range (“Showing rows 11 to 20 of 240”) in a live region, and keep the table’s header relationships intact on every page.

What automated scanning can and cannot tell you

Automated tools are good at spotting markup issues: a navigation region with no name, a missing aria-label, an invalid attribute, a link with no text. They are weaker at judging whether the focus order makes sense, whether the announcement after a page change is useful, or whether a label is meaningful in context.

The U.S. Access Board is direct about this. Its web guide explains that assistive technologies are complex and that testing without experience can produce inaccurate results. A passing scan therefore does not prove that your pagination, or your site, meets a legal standard. The same applies to the accessibility of your whole site: good SEO and good accessibility overlap in structure and navigation, but neither replaces actual testing.

A reliable workflow combines three layers:

Automated scans to find code-level issues across many pages and catch regressions.
Manual keyboard checks using the five-step test above.
Screen reader checks with a tool such as NVDA. Our two-pass NVDA and Firefox testing guide shows a repeatable way to do it.

For the bigger picture on building these layers into releases, see our WCAG 2.2 testing workflow for CI/CD.

A pagination checklist you can copy

The pager is inside a nav with a unique, concise accessible name.
Items are in a ul, and page changes that change the URL use a elements.
Exactly one item has aria-current="page", with a non-color visual indicator.
Each control has a meaningful name: “Page 3,” “Previous page,” “Next page.”
Previous and Next are hidden or removed (not just grayed out) when they do not apply, or are marked as unavailable in a way that is announced.
The ellipsis is plain text, not focusable.
Targets are at least 44 by 44 CSS pixels with spacing.
Focus is visible on every control and never trapped.
Dynamic updates move or preserve focus sensibly and announce the new state.
The page also offers search, filters or categories.
The layout holds up at 200 percent zoom and on small screens.

Our perspective: fix the code, then keep the proof

We built AccessWiser around a simple belief: accessibility should be permanent, not patched on top. A pager is a perfect example. You can cover a broken one with a runtime overlay, but the underlying div soup is still there for the next redesign to inherit. Changing the markup once means every visitor, with every device and assistive technology, benefits for good.

Our perspective: fix the code, then keep the proof — overview diagram

We also believe in being honest about automation. Scans detect a substantial subset of barriers, and they are excellent at pointing to the exact element and criterion affected. They are not a verdict on conformance. That is why we pair findings with plain-language guidance for fixing them in your own code, scheduled re-checks that catch regressions when someone updates a theme or plugin, and dated records of scans and fixes. Those records show a clear trail of effort, and they support a wider compliance program that also includes manual and user testing.

If you have a pager today, you do not need a rebuild. You need a named landmark, a current-page marker, labels, larger targets and a keyboard test. That is an afternoon of work for most sites, and it makes a visible difference.

— The AccessWiser Team

Check your pagination across the whole site

Pagination appears on dozens or hundreds of templates, and it is easy to fix one and miss the rest. AccessWiser scans your site against WCAG 2.2 AA with Section 508 and EN 301 549 mappings, ties each issue to the element and criterion it affects, and explains the fix in plain language. Scheduled re-checks flag regressions, and dated records support your documentation, including an accessibility statement.

Plans start at $24 per month (Starter), with Basic at $49 per month and Pro at $119 per month, and there is a 7-day free trial. Extra specific page scans cost $12 one-off and extra full site scans cost $19 one-off. See plans and pricing or browse accessibility solutions for every website.

If you build components with similar interaction patterns, our guides to accessible tabs, accordions and carousels apply many of the same ideas.

FAQ

How do I make pagination accessible?

Use a nav element with a unique accessible name, a list of real links, meaningful labels such as “Page 3” and “Next page,” and aria-current="page" on the current item. Keep a visible focus state and make targets large. Then test with a keyboard, a screen reader, zoom and a phone.

Is infinite scroll accessible?

Automatic infinite scroll is hard to make accessible because it can hide the footer, break the Back button and leave screen reader users unaware that new content loaded. A “Load more” button or numbered pagination is safer. Whichever you choose, manage focus, announce updates and keep search or filters available.

Should pagination use links or buttons?

Use links when activation changes the URL, which is the common case. Use buttons for in-place actions such as “Load more.” Choosing the right element gives you the expected keyboard and screen reader behavior without extra scripting.

Does accessible pagination make my site legally compliant?

No. One accessible component is one piece of a larger picture, and the Access Board cautions that tool results alone are not a complete determination. Combine automated scans, manual keyboard testing and screen reader checks, and keep dated records. If you face a legal demand or complaint, talk to an attorney experienced in digital accessibility.