A Colombian newspaper ran a piece recently about infinite scroll as a thief of time, with psychologists explaining the reward loop and readers being told to set alarms every fifteen minutes. It is a fair article. It is also aimed at the wrong audience. The people who can actually fix infinite scroll are not the ones scrolling. They are the ones shipping it.<\/p>\n\n\n\n
Aza Raskin built the pattern in 2006 as a navigation convenience and has spent years since saying he regrets it. Twenty years later it is a default. Somebody reaches for a feed, somebody wires up an Here is the part the wellness coverage misses: infinite scroll is not only an attention problem. It is one of the most reliable ways to ship an inaccessible page. I have audited enough interfaces against WCAG for the US market to say that with some confidence. The same design decision that removes the ending for a casual reader removes the entire footer for a keyboard user.<\/p>\n\n\n\n Physical media has closure signals built in. A book has a last page. A film has credits. A paginated list has a page 4 of 4. Those endings are not decoration, they are the moment a person gets to decide whether to continue.<\/p>\n\n\n\n Infinite scroll deletes that moment. And once you delete it, four technical failures tend to follow, all of them mine to fix as the person writing the component.<\/p>\n\n\n\n This is the one that shows up in every audit. Your privacy policy, contact link, accessibility statement, and legal pages live in the footer. A sighted mouse user can hammer End and maybe catch it. A keyboard user tabbing forward never arrives, because every time they approach the bottom, twenty new focusable links get injected ahead of the footer. The footer recedes forever.<\/p>\n\n\n\n That is a WCAG 2.1.1 and 2.4.3 problem, and in a US compliance context it is the kind of finding that ends up in a demand letter. It is also completely avoidable.<\/p>\n\n\n\n You appended thirty articles to the DOM. A screen reader user has no idea. There was no announcement, no focus change, no status message. From their side the page simply did nothing, forever.<\/p>\n\n\n\n User scrolls through 200 items, opens one, hits back, and lands at item 1. This is not a minor annoyance, it is the single most common complaint about infinite scroll in ecommerce catalogs, and it is a direct revenue problem. Every restart is an abandonment opportunity.<\/p>\n\n\n\n Without virtualization, node count grows without bound. Layout and paint costs climb with it, CLS degrades as images settle in, and on a mid range Android phone the thing eventually just stops responding. Anyone who has run Lighthouse on a long feed has seen the curve.<\/p>\n\n\n\n A Load more button. That is it. It costs one click and it fixes almost everything above at once: the footer stays reachable, the user keeps an explicit decision point, back navigation is trivial to restore, and the growth of the DOM is bounded by intent instead of by inertia.<\/p>\n\n\n\n Three details in there matter more than the rest. The Keep Sometimes the product decision is already made and you are not going to win that argument. Fine. You can still make it survive an audit by treating the observer as a progressive enhancement on top of a real button rather than a replacement for one.<\/p>\n\n\n\n The cap is the whole point. After three automatic loads the sentinel stops firing and the button takes over permanently. The user gets the frictionless experience the product manager wanted for the first stretch, and then the interface hands control back. The footer becomes reachable again. Nobody scrolls for forty minutes by accident.<\/p>\n\n\n\n The The back button problem has a boring fix that almost nobody implements: put the page count in the URL and let the browser do its job.<\/p>\n\n\n\n Use It is not always wrong. The distinction that has held up for me is whether the user has a task.<\/p>\n\n\n\n The advice in consumer articles is all downstream: set a timer, grayscale the screen, leave the phone in another room. None of it is bad. All of it asks the user to individually out discipline a system built by teams of people who were paid to remove their stopping points.<\/p>\n\n\n\n We are on the other side of that. A count in an announcement, a button after three loads, a footer that stays where you put it. These are half a day of work and they hand people back the thing the pattern quietly took, which is the ability to notice they are finished.<\/p>\n\n\n\n The accessibility case and the ethical case turn out to be the same case. That happens more often than you would expect.<\/p>\n\n\n\n Context and reporting on the consumer side of this pattern: El Tiempo, Dejar el scroll infinito y volver a ser due\u00f1o de su tiempo<\/a> (Spanish).<\/em><\/p>\n\n\n\nIntersectionObserver<\/code>, and the last page quietly stops existing.<\/p>\n\n\n\nWhat the pattern actually removes<\/h2>\n\n\n\n
1. The footer becomes unreachable<\/h3>\n\n\n\n
2. New content arrives silently<\/h3>\n\n\n\n
3. Back navigation loses the position<\/h3>\n\n\n\n
4. The page gets heavier until it dies<\/h3>\n\n\n\n
The default that should have been the default<\/h2>\n\n\n\n
function ResultsList({ items, hasMore, onLoadMore, loading }) {\n const [announcement, setAnnouncement] = useState(\"\");\n const firstNewRef = useRef(null);\n const previousCount = useRef(items.length);\n\n useEffect(() => {\n const added = items.length - previousCount.current;\n if (added > 0) {\n setAnnouncement(`${added} more results loaded. ${items.length} of ${total} shown.`);\n firstNewRef.current?.focus();\n }\n previousCount.current = items.length;\n }, [items.length]);\n\n return (\n <>\n <ul>\n {items.map((item, i) => (\n <li key={item.id}>\n <a\n href={item.href}\n ref={i === previousCount.current ? firstNewRef : null}\n tabIndex={-1}\n >\n {item.title}\n <\/a>\n <\/li>\n ))}\n <\/ul>\n\n <p role=\"status\" aria-live=\"polite\" className=\"visually-hidden\">\n {announcement}\n <\/p>\n\n {hasMore && (\n <button type=\"button\" onClick={onLoadMore} disabled={loading}>\n {loading ? \"Loading\u2026\" : \"Load more results\"}\n <\/button>\n )}\n <\/>\n );\n}<\/code><\/pre>\n\n\n\nrole=\"status\"<\/code> region with aria-live=\"polite\"<\/code> announces the change without interrupting whatever the user is reading. Moving focus to the first newly added item means a keyboard user resumes exactly where the new content begins rather than at the top. And the count in the announcement, 60 of 240 shown<\/em>, is the closure signal the pattern threw away. People deserve to know how much is left.<\/p>\n\n\n\nvisually-hidden<\/code> as a clip based utility, not display: none<\/code>. Hidden elements are removed from the accessibility tree and your announcement will never fire.<\/p>\n\n\n\nIf you genuinely need automatic loading<\/h2>\n\n\n\n
const sentinelRef = useRef(null);\nconst [autoLoads, setAutoLoads] = useState(0);\nconst MAX_AUTO_LOADS = 3;\n\nuseEffect(() => {\n const el = sentinelRef.current;\n if (!el || !hasMore || autoLoads >= MAX_AUTO_LOADS) return;\n\n const reducedMotion = window.matchMedia(\"(prefers-reduced-motion: reduce)\").matches;\n if (reducedMotion) return;\n\n const observer = new IntersectionObserver(\n ([entry]) => {\n if (entry.isIntersecting) {\n onLoadMore();\n setAutoLoads((n) => n + 1);\n }\n },\n { rootMargin: \"400px\" }\n );\n\n observer.observe(el);\n return () => observer.disconnect();\n}, [hasMore, autoLoads, onLoadMore]);<\/code><\/pre>\n\n\n\nrootMargin<\/code> of 400px preloads before the user hits the bottom so it still feels instant. And respecting prefers-reduced-motion<\/code> here is not strictly required by the spec, but users who set it are generally telling you they do not want the page moving on its own.<\/p>\n\n\n\nRestoring scroll position without a library<\/h2>\n\n\n\n
\/\/ after each successful load\nconst url = new URL(window.location);\nurl.searchParams.set(\"loaded\", String(page));\nwindow.history.replaceState({ page, scrollY: window.scrollY }, \"\", url);\n\n\/\/ on mount\nconst restore = Number(new URLSearchParams(location.search).get(\"loaded\")) || 1;\n\/\/ fetch pages 1..restore, then:\nrequestAnimationFrame(() => {\n window.scrollTo(0, history.state?.scrollY ?? 0);\n});<\/code><\/pre>\n\n\n\nreplaceState<\/code> rather than pushState<\/code> so you are not stuffing the history stack with one entry per scroll batch. Refetching several pages on return is not free, but it is cheaper than losing the session, and it makes the URL shareable at the depth the user actually reached.<\/p>\n\n\n\nWhen infinite scroll is the right call<\/h2>\n\n\n\n
\n\n
The part that is on us<\/h2>\n\n\n\n
\n\n\n\n