VirtualList: 50,000 Rows, 12 in the DOM, Honest Screen Reader Counts

Rendering 50,000 DOM nodes is slow to create, slow to lay out and expensive to keep in memory. Virtualisation renders only what is visible — around twelve rows for a typical viewport — plus a small buffer, and translates them as the user scrolls. Spacer elements preserve the scrollbar so the page still feels like it contains 50,000 rows.

Visually this is a solved problem and several libraries do it well. The part that is routinely wrong is what the DOM now claims about itself, because the DOM genuinely contains twelve items and the user is genuinely looking at item 4,201.

A screen reader describes a list by its position and size. If the implementation lets those attributes reflect the rendered window, the user hears 'item 4 of 12' while scrolled to the middle of a 50,000-row dataset. The number is not just unhelpful, it is confidently wrong.

`aria-posinset` and `aria-setsize` exist precisely for this: they let you state the true position and total independently of what is in the DOM. Set honestly, the user hears 'item 4,201 of 50,000' — which is what a sighted user infers from the scrollbar.

Pressing the down arrow at the bottom of the rendered window has to load and focus the next item in the dataset, not stop because the DOM ran out. Home and End should move to the first and last item of the whole list, which in a virtualised list means scrolling to a position that is not currently rendered at all.

This is where naive implementations break most visibly: focus lands on an element, the list scrolls, that element is recycled or removed, and focus falls back to the document body. The user is silently returned to the top of the page.

Recycling DOM nodes is what makes virtualisation fast, and it is directly hostile to focus. If the node holding focus is reused for different data, focus stays on a node that now represents something else — the user's context is gone without any indication.

The handling is to track focus by data identity rather than by node, and to restore it when the corresponding item re-renders. Any virtualised list you evaluate should be tested by focusing an item, scrolling far away, and scrolling back.

Virtualisation costs complexity, breaks in-page find, breaks Ctrl+F, and complicates printing and copy-paste. For a few hundred rows it is not worth any of that — browsers render a few hundred rows without complaint.

The threshold is roughly where scrolling becomes visibly janky on a mid-range device, and that depends far more on row complexity than row count. A thousand rows of plain text is fine; two hundred rows each containing an avatar, three badges and a chart is not.

Three checks catch nearly everything. Focus an item, scroll far, scroll back — is focus still on the right item? Turn on a screen reader and navigate — does it announce the true total? Press End — does it reach the actual last item?

Run these on a throttled CPU rather than a fast laptop. Virtualisation bugs are timing-dependent, and a fast machine hides the window where the DOM and the data disagree.