Making Pagination, “Load More,” and Infinite Scroll Accessible for E-Commerce
Quick answer: Category pages, search results, and review lists almost always use one of three
patterns to show more items than fit on one screen: numbered pagination links, a “Load more”
button, or auto-loading infinite scroll. Each has a different accessibility requirement — numbered
pagination needs aria-current="page" and link text that makes sense out of context (WCAG SC
2.4.4), a “Load more”
button needs an accessible name plus a status-message announcement when new results land (SC
4.1.2, SC
4.1.3), and infinite scroll
needs either the WAI-ARIA feed role
or a way to reach the footer without it (SC 2.4.1 Bypass
Blocks).
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA is a technical-practice standard, not a legal determination — consult qualified counsel for legal risk questions.
Numbered pagination: mark the current page, name the links
Numbered pagination — “1 2 3 … 12” at the bottom of a category or search-results page — is
mostly a solved problem, and the W3C’s own Design System documents the reference
markup directly: “The current page is
indicated by aria-current="page"… it is fully linked so that users of Assistive Technology can
find which is the currently active link.” 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’re
on from the visual highlight; aria-current="page" is the same information for a screen reader.
The second piece is easy to skip: the pagination controls sit inside their own <nav> landmark,
and that landmark needs its own accessible name, because it’s not the only <nav> on the page. The
Design System’s own guidance: “Where there are multiple <nav> elements on a single page, they
should all have a unique accessible name” — a category page already has a main site-navigation
<nav>, so the pagination region needs aria-label="Pagination" (or aria-labelledby pointing to
a visually hidden heading) to tell the two apart. This is the same aria-current/landmark-naming
pattern our breadcrumb navigation article
covers in more depth for the breadcrumb trail specifically — worth reading there for the full
mechanism if pagination is the only place you’re applying it, this section won’t repeat it.
What pagination adds on top of that: the links themselves. WCAG SC 2.4.4 Link Purpose (In
Context) requires that
“the purpose of each link can be determined from the link text alone or from the link text together
with its programmatically determined link context.” A bare “2” or “3” passes this in practice
because it sits inside a <nav> with other numbered links around it — the context makes the
purpose clear, the same way the criterion’s own example (a game with links labeled “door #1,”
“door #2”) accepts ambiguity that applies equally to everyone. What doesn’t pass: icon-only
previous/next arrows (‹ ›) with no text at all and no aria-label. A screen reader announces
those as “link” or reads the raw glyph — give each one a real name: aria-label="Previous page"
and aria-label="Next page".
“Load more” buttons: name it, then announce what changed
A “Load more” or “Show more results” button avoids the multi-page-navigation problem entirely by
appending more items to the same page. It’s a plain <button>, so SC 4.1.2 Name, Role,
Value is usually satisfied by
default — the failure mode here isn’t a missing role, it’s an icon-only version of the same button
(a bare “+” or down-chevron with no text) shipping with no accessible name, same as the pagination
arrows above.
The part that’s easy to miss entirely: what happens after the click. A sighted user sees new
product cards appear below the button. A screen reader user, whose focus never moved off the
button, hears nothing unless the new content is announced. SC 4.1.3 Status
Messages exists for exactly
this — its own Intent: “to make users aware of important changes in content that are not given
focus, and to do so in a way that doesn’t unnecessarily interrupt their work.” The Understanding
doc’s own worked example is almost the exact shape of a “Load more” click: “the page content is
updated to include the results of the search… The change to content also includes the message
‘5 results returned’ near the top of this new content.” Applied to “Load more,” that’s a small
aria-live="polite" region — near the button, not buried at the top of the newly appended items —
that updates to something like “12 more products loaded” each time the button is pressed. Without
it, a screen reader user has no way to know the click did anything at all beyond continuing to tab
forward and eventually landing on new content with no announcement that it’s new.
Infinite scroll: the pattern that needs the most care
Auto-loading infinite scroll — new items appear automatically as a user scrolls near the bottom,
with no button click at all — is the pattern with the fewest built-in accessibility guarantees, and
the WAI-ARIA APG’s own Infinite Scrolling Feed
Example is explicit that it needs
deliberate work, not a default HTML behavior. role="feed" identifies “the element that contains
the set of feed articles” as a structural container, with each article made focusable
(tabindex="0") so a screen reader’s reading cursor tracks the content as new items load. The
pattern’s own keyboard model uses Page Down/Page Up to move between articles and Control+End/Home
to jump past the feed entirely — deliberately different from a normal Tab-through-links flow,
because a feed can be arbitrarily long.
Two things worth taking seriously before shipping this pattern. First, the APG page states its own limitation plainly: “There may be support gaps in some browser and assistive technology combinations, especially for mobile/touch devices. Testing code based on this example with assistive technologies is essential before considering use in production systems.” That’s the pattern’s own authors, not a critique from outside it — infinite scroll is a harder problem than pagination or “Load more,” and the fix requires real testing, not just adding the ARIA attributes and assuming it works.
Second, and more concretely: an infinite-scroll feed with no way past it can trap a keyboard or
screen-reader user above the footer. This is a real, documented failure mode rather than a
theoretical one — the W3C WCAG Working Group’s Mobile Accessibility Task Force described it
directly in an internal working draft (fetched
directly for this article; the document itself is explicit that it’s “an internal working
draft… updated continuously and without notice,” never
finalized as a W3C Recommendation, so it’s cited here as an illustration of a real, named failure
mode, not as an adopted WCAG requirement): “Infinite scroll of content, where there is additional
content in the footer, but the user with assistive technology (e.g. screenreader) cannot move
focus to the footer and therefore cannot read the footer content and may not even know that the
footer content exists.” SC 2.4.1 Bypass Blocks
— “a mechanism is available to bypass blocks of content that are repeated on multiple web pages” —
is the closest formal WCAG hook for the general shape of this problem, and it’s why the practical
fix isn’t “implement role="feed" perfectly.” It’s simpler: ship a “Load more” button or numbered
pagination as the real mechanism, and treat auto-loading infinite scroll as a progressive
enhancement layered on top of it, not the only way to reach page 2 or the footer.
A quick manual test
- Tab through numbered pagination. Does the current page announce as current (
aria-current) via a screen reader, not just a visual highlight? Do the prev/next arrows have real names, or does a screen reader just say “link”? - Click “Load more” with a screen reader running. Does anything get announced, or does the screen reader stay silent while new items appear below?
- Scroll an infinite-scroll list using only the keyboard, with a mouse unplugged. Can you reach the footer at all? If Tab or Page Down never gets you past the feed, that’s the trap described above.
- Check icon-only controls specifically — bare arrows, a “+” load-more icon — with a screen reader. Anything read as just “button” or “link” with no further text has no accessible name.
FAQ
Do I need all three patterns, or can I pick one?
Pick the one that fits the page. Numbered pagination and “Load more” buttons are each fully
accessible on their own with the fixes above — neither requires infinite scroll’s extra
role="feed" complexity. If a design calls for infinite scroll specifically (a common choice for
mobile category browsing), the safest build still includes a manual “Load more” trigger or
pagination link as a fallback, per the footer-trap risk above.
Does adding role="feed" alone make infinite scroll accessible?
No — the APG pattern documents the full keyboard model and focusable-article structure that has to
ship alongside the role, and its own authors flag real support gaps that need testing. The role by
itself doesn’t solve the footer-access problem either.
What about “Back to top” buttons on long infinite-scroll pages?
Out of scope for this article, but the same accessible-name rule applies: if it’s an icon-only
button, it needs a real aria-label, same as the pagination arrows above.
Get a human-reviewed audit, not just a scan
An automated scanner can flag a missing aria-label on an icon-only pagination arrow. It generally
can’t tell you whether a screen reader user can actually tab past an infinite-scroll feed to reach
your footer, or whether a “Load more” click gets announced at all — both require operating the page
with a keyboard and a screen reader, not just parsing the DOM. Quietramp’s audits pair an automated
scan with that kind of manual review, delivered as a prioritized, developer-actionable PDF report.
See a real sample report or check pricing — $890 one-time,
$99/month for ongoing re-checks after fixes ship.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.