Reviewed November 11, 2026

Accessible Pagination: The Row of Numbers With No Map

Pagination is the row of numbered links at the bottom of a collection page, Previous, 1, 2, 3, 12, Next, and for a screen reader user it is often a row of numbers with no map. The current page is not marked, the Previous and Next controls are arrow icons with no names, the numbers are too small to tap, and after the page changes, nothing is announced, so the shopper does not know where they are. The fix is small and standard: wrap the controls in a nav landmark with its own accessible name, mark the current page with aria-current="page", give Previous and Next real names, make every control at least 24 by 24 CSS pixels with 4.5 to 1 contrast, and announce the new range in a live region when the page changes. A well-built pagination pattern is a named navigation region that holds a list of real links, marks the current page, works from the keyboard with a visible focus indicator, and uses controls large enough to tap.

The row of numbers with no map

Pagination is the row of numbered links, Previous, 1, 2, 3, 12, Next, that sits at the bottom of a collection page, a blog archive, or a page of search results. For a sighted shopper it is a map: the highlighted number says where you are, and the arrows say where you can go. For a screen reader user it is often a row of numbers with no map at all. The current page is not marked, so the shopper hears 1, 2, 3, 4 and does not know which one they are on. The Previous and Next controls are arrow icons with no names, so the screen reader announces link, or reads the raw glyph. The numbers are too small to tap reliably, and after the page changes, nothing is announced, so the shopper does not know the results changed, or which results they are now looking at. 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.

The five fixes, in order

The first fix is the landmark. Wrap the whole set of controls in a nav element with a unique accessible name, such as aria-label="Pagination", because the page already has a main site-navigation nav, and without a name the screen reader user hears two unlabeled navigation regions. The second fix is the current page. Put aria-current="page" on exactly one item, and pair it with a visual indicator that does not rely on color alone, a border, bold weight, or underline in addition to a fill, so sighted users and screen reader users get the same information. The third fix is the names. Give Previous and Next real, descriptive names, either visible text or a screen-reader-only label behind the icon, and add context to the numbers, such as Page 3, through an aria-label or visually hidden text. The fourth fix is the targets and the contrast. Numbers need a contrast ratio of at least 4.5 to 1 against their background under WCAG 1.4.3, and interactive targets need to be at least 24 by 24 CSS pixels under WCAG 2.2 criterion 2.5.8, the Level AA minimum. The stricter Level AAA figure is 44 by 44, the same number Apple uses, and on mobile the full numbered pagination collapses badly, so simplify to Previous and Next. The fifth fix is the announcement. After a page change, move focus to the new content and announce the change with a short, polite live-region message such as Showing results 21 to 40 of 240, so the shopper knows where they are without having to go looking for it.

The states that get forgotten

Two states are forgotten more often than the rest. Disabled controls, Previous on the first page and Next on the last, should be genuinely disabled, not just faded. Use aria-disabled="true", which communicates the state while keeping the element in the accessibility tree for discovery, rather than removing it from the page. And the current page should stay a real, focusable link, not a de-linked span, because a sighted user sees which page they are on from the visual highlight, and the screen reader user needs the same information delivered through markup. Persist the page number in the URL, not in session storage, so pages stay bookmarkable and crawlable, and so a shopper who shares a link shares the right page. Automated scans catch the markup problems, the missing landmark, the missing aria-current, the missing names, but keyboard and screen reader checks are still needed, because a scan cannot tell you whether the announcement after a page change actually happens, or whether the focus indicator is visible when you Tab to a page number. Test it with a keyboard and a screen reader, and keep dated records of both.

Frequently asked questions

What is aria-current="page", and why does pagination need it?

It is a small, standardized attribute that marks the 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. The current-page item stays a real, focusable link rather than being de-linked or greyed out with no markup: a sighted user sees which page they are on from the visual highlight, and aria-current="page" is the same information for a screen reader. Put it on exactly one item.

Why does pagination need its own nav landmark?

Because most pages already have a main site-navigation nav, and if the pager has no name, a screen reader user hears two unlabeled navigation regions and cannot tell them apart. Wrap the whole set of controls in a nav element with a label such as aria-label="Pagination", or aria-labelledby pointing to a visually hidden heading. If a page has more than one pager, each needs a distinct name, such as Search results pages. The W3C Design System documents this exact pattern.

What is wrong with arrow-only Previous and Next buttons?

A screen reader announces an icon-only arrow as link, or reads the raw glyph, which tells the shopper nothing. Give each control a real name: aria-label="Previous page" and aria-label="Next page", or visible text. A link that announces only 3 tells a screen reader user little, so add context such as Page 3 through an aria-label or visually hidden text. 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.

Should I use numbered pagination, Load more, or infinite scroll?

Numbered pagination is the most accessible of the three, because it is a solved problem with a standard pattern. A Load more button avoids multi-page navigation, but it needs an accessible name plus a status-message announcement when new results land, under WCAG 4.1.2 and 4.1.3. Infinite scroll is the hardest: it needs either the WAI-ARIA feed role or a way to reach the footer without it, under WCAG 2.4.1 Bypass Blocks, because a keyboard user who can never reach the footer can never leave the page. If you use infinite scroll, offer a Load more button or real paging alongside it.