Build an accessible virtualized feed

Virtualization improves performance by making most of the document disappear.

That trade is reasonable only if the remaining document still tells the truth. A screen reader needs meaningful items and position. Keyboard focus cannot vanish when an item scrolls outside the window. Prepending older results cannot throw the reading point. Variable-height content cannot keep correcting the page until the user loses where they were.

The W3C ARIA Authoring Practices feed pattern defines a feed as a dynamic list of articles and describes focus-based loading, Page Up and Page Down navigation, aria-posinset, and aria-setsize when the complete set is not in the DOM. It also makes an important point: the interaction contract exists partly so assistive technology can control which content is loaded.

I would separate the logical feed from its rendered window. Stable item keys, indices, measurements, cursor state, and focus live outside mounted cards. Virtualization then becomes one rendering strategy with an escape hatch, not the data model.

Performance wins only count when a user can leave, return, navigate, and understand position without the feed rearranging their task.

Choose virtualization for the task

Profile real item counts, DOM complexity, device constraints, interaction patterns, and accessibility needs before accepting the semantic and implementation cost of windowing.

I would pressure-test that decision with four questions:

• What performance problem exists now?
• How many complex nodes cause it?
• Do users search or compare across items?
• Would pagination solve the task better?

The failure mode here is adding a windowing library because the list might grow someday. In activity streams, recruiter inboxes, audit logs, social timelines, search results, and monitoring views that may contain thousands of variably sized items while keyboard, screen-reader, zoom, find, focus, and scroll behavior still need a coherent document, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a virtualization suitability scorecard. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is measured improvement on target devices without removing required workflows. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a virtualization suitability scorecard beside the question “What performance problem exists now?” before the first implementation review. The next pass would use “How many complex nodes cause it?” to test the boundary, then “Do users search or compare across items?” to expose the state most likely to be missed. I would keep “Would pagination solve the task better?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports measured improvement on target devices without removing required workflows.

Model a stable logical sequence

Item identity, order, cursor boundaries, total knowledge, selection, focus, measurements, and mutation rules should remain stable independently of component mount state.

The practical review starts here:

• What key survives refresh?
• Can insertion reorder existing items?
• Is total known?
• Where does selection live?

Those questions keep using array index and mounted component state as durable identity from becoming the default. I would capture the decision in a logical-feed state model, then use it while the work is still cheap to change. For large feeds that reduce DOM cost without making content position or keyboard access fictional, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like updates preserving the same semantic item and operator state. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a logical-feed state model part of the working surface. I would use it to answer “What key survives refresh?” while scope is still flexible, and “Can insertion reorder existing items?” before code or content becomes expensive to unwind. During QA, “Is total known?” and “Where does selection live?” become concrete checks rather than discussion prompts. That sequence turns large feeds that reduce DOM cost without making content position or keyboard access fictional into something the team can operate and gives me a specific outcome to report: updates preserving the same semantic item and operator state.

Expose feed and article semantics

Use the feed pattern only when its interaction contract fits, label the feed, make each item an article with an accessible name, and publish position and set size accurately or use the defined unknown value.

Before implementation, I would answer:

• Is this truly a feed?
• What names each article?
• Are posinset values global?
• Is set size known or unknown?

The artifact is an accessibility-tree contract. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is adding role feed while omitting the keyboard and loading behavior the role communicates; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is tested assistive technology announcing useful identity and position. That connects a windowed feed architecture that keeps semantic item identity and position stable, moves a rendering window around focus and viewport, measures variable height without jumps, loads in both directions, restores anchors, and falls back when virtualization harms the task to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Is this truly a feed?” easy to answer. The boundary should force a decision about “What names each article?” and “Are posinset values global?.” I would record both in an accessibility-tree contract, including the part that stayed unresolved after the first pass. The final check, “Is set size known or unknown?,” is where the artifact earns its place: it either supports tested assistive technology announcing useful identity and position, or it shows exactly why another iteration is needed.

Keep focus mounted

A focused element must not be unmounted; the window can expand or pin its containing article until focus moves through an intentional command to another mounted target.

I would use these prompts during the working review:

• Can scrolling evict focus?
• What happens to an open menu?
• How does focus move between articles?
• When may a pinned item release?

If the team slips into letting recycling remove the active element and reset focus to body, the product can still look complete while its operating rule stays ambiguous. I would make a focus-pinning state machine the shared reference and keep it small enough to update as evidence changes.

The standard is keyboard focus surviving scroll, resize, load, and dynamic-height changes. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a focus-pinning state machine, review it against “Can scrolling evict focus?,” implement the narrowest useful path, and then return with evidence for “What happens to an open menu?.” I would use “How does focus move between articles?” to inspect product consequence and “When may a pinned item release?” to decide whether the result is stable enough to ship. This keeps letting recycling remove the active element and reset focus to body visible as a known risk and makes keyboard focus surviving scroll, resize, load, and dynamic-height changes the release receipt rather than a hopeful conclusion.

Navigate by meaningful units

Page Up and Page Down or equivalent commands should move between article start or end positions, load additional content when needed, and avoid hijacking ordinary controls inside an item.

I would pressure-test that decision with four questions:

• Which keys move between items?
• What if focus is inside a button?
• How is new content requested?
• What is announced on arrival?

The failure mode here is binding global arrow keys that break text fields and native scrolling. In activity streams, recruiter inboxes, audit logs, social timelines, search results, and monitoring views that may contain thousands of variably sized items while keyboard, screen-reader, zoom, find, focus, and scroll behavior still need a coherent document, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a feed keyboard interaction map. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is repeatable movement through items without trapping nested interactions. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a feed keyboard interaction map beside the question “Which keys move between items?” before the first implementation review. The next pass would use “What if focus is inside a button?” to test the boundary, then “How is new content requested?” to expose the state most likely to be missed. I would keep “What is announced on arrival?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports repeatable movement through items without trapping nested interactions.

Measure variable height safely

Start with reasonable estimates, observe mounted item size, batch updates, avoid ResizeObserver feedback loops, and record measurements by stable key and width regime.

The practical review starts here:

• What invalidates a measurement?
• Are updates batched?
• Can images change height later?
• Does responsive width need a new cache?

Those questions keep measuring every item synchronously during render from becoming the default. I would capture the decision in a variable-height measurement cache, then use it while the work is still cheap to change. For large feeds that reduce DOM cost without making content position or keyboard access fictional, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like bounded layout work and stable estimates across representative content. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a variable-height measurement cache part of the working surface. I would use it to answer “What invalidates a measurement?” while scope is still flexible, and “Are updates batched?” before code or content becomes expensive to unwind. During QA, “Can images change height later?” and “Does responsive width need a new cache?” become concrete checks rather than discussion prompts. That sequence turns large feeds that reduce DOM cost without making content position or keyboard access fictional into something the team can operate and gives me a specific outcome to report: bounded layout work and stable estimates across representative content.

Preserve the scroll anchor

When measurements or prepended pages change height before the reading point, calculate the delta around a named anchor and compensate without fighting intentional user scroll.

Before implementation, I would answer:

• Which item anchors the viewport?
• What is its intra-item offset?
• Did change occur before it?
• Is the user actively scrolling?

The artifact is an anchor-compensation algorithm. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is restoring a raw scrollTop after content above changed; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is the same item and visual offset remaining stable through prepend and resize. That connects a windowed feed architecture that keeps semantic item identity and position stable, moves a rendering window around focus and viewport, measures variable height without jumps, loads in both directions, restores anchors, and falls back when virtualization harms the task to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which item anchors the viewport?” easy to answer. The boundary should force a decision about “What is its intra-item offset?” and “Did change occur before it?.” I would record both in an anchor-compensation algorithm, including the part that stayed unresolved after the first pass. The final check, “Is the user actively scrolling?,” is where the artifact earns its place: it either supports the same item and visual offset remaining stable through prepend and resize, or it shows exactly why another iteration is needed.

Load bidirectionally with backpressure

Top and bottom sentinels, cursors, request identity, cancellation, deduplication, retry, and bounded prefetch should extend the logical sequence without duplicate or reordered items.

I would use these prompts during the working review:

• Which cursor is in flight?
• Can requests overlap?
• How are duplicate items merged?
• Does fast scrolling cancel obsolete work?

If the team slips into triggering a request on every observer callback and appending responses by arrival time, the product can still look complete while its operating rule stays ambiguous. I would make a bidirectional paging controller the shared reference and keep it small enough to update as evidence changes.

The standard is one ordered page per cursor with bounded requests and recoverable errors. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a bidirectional paging controller, review it against “Which cursor is in flight?,” implement the narrowest useful path, and then return with evidence for “Can requests overlap?.” I would use “How are duplicate items merged?” to inspect product consequence and “Does fast scrolling cancel obsolete work?” to decide whether the result is stable enough to ship. This keeps triggering a request on every observer callback and appending responses by arrival time visible as a known risk and makes one ordered page per cursor with bounded requests and recoverable errors the release receipt rather than a hopeful conclusion.

Restore semantic position

Persist route, item key, intra-item offset, filters, and data version; on return, load the needed page, mount the target, measure, and restore progressively rather than guessing one pixel offset.

I would pressure-test that decision with four questions:

• Which item was the user reading?
• Can it still be found?
• What if order changed?
• When is restoration complete?

The failure mode here is saving scrollTop alone and restoring before data or measurements exist. In activity streams, recruiter inboxes, audit logs, social timelines, search results, and monitoring views that may contain thousands of variably sized items while keyboard, screen-reader, zoom, find, focus, and scroll behavior still need a coherent document, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a key-based navigation restoration receipt. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is back navigation returning to the intended item within a measured tolerance. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a key-based navigation restoration receipt beside the question “Which item was the user reading?” before the first implementation review. The next pass would use “Can it still be found?” to test the boundary, then “What if order changed?” to expose the state most likely to be missed. I would keep “When is restoration complete?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports back navigation returning to the intended item within a measured tolerance.

Test product and performance together

QA should cover screen readers, keyboard, zoom, reduced motion, browser find expectations, dynamic insertion, deletion, prepend, resize, images, focus inside controls, back navigation, slow network, and low-end devices.

The practical review starts here:

• Is position announced correctly?
• Can focus ever disappear?
• Does the anchor drift?
• Did performance improve where it mattered?

Those questions keep shipping from a smooth developer-laptop scroll trace alone from becoming the default. I would capture the decision in an accessible virtualization test matrix, then use it while the work is still cheap to change. For large feeds that reduce DOM cost without making content position or keyboard access fictional, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like DOM, interaction, and restoration budgets holding in representative workflows. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make an accessible virtualization test matrix part of the working surface. I would use it to answer “Is position announced correctly?” while scope is still flexible, and “Can focus ever disappear?” before code or content becomes expensive to unwind. During QA, “Does the anchor drift?” and “Did performance improve where it mattered?” become concrete checks rather than discussion prompts. That sequence turns large feeds that reduce DOM cost without making content position or keyboard access fictional into something the team can operate and gives me a specific outcome to report: DOM, interaction, and restoration budgets holding in representative workflows.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a virtualization suitability scorecard
• a logical-feed state model
• an accessibility-tree contract
• a focus-pinning state machine
• a feed keyboard interaction map

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because a windowed feed architecture that keeps semantic item identity and position stable, moves a rendering window around focus and viewport, measures variable height without jumps, loads in both directions, restores anchors, and falls back when virtualization harms the task becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# sequence
5,240 known items / cursor after c_71
Keys stable, total known, 34 measured heights, estimate 112px, overscan 6, focused item k_482 pinned.
# render
21 articles / 38ms longest update
DOM nodes 486, layout shift 0.002, ResizeObserver batch 4, no synchronous measure loop, memory 24 MiB.
# navigation
restore k_482 + 37px / error 1px
Page Down announces item 483 of 5240, prepend anchor drift 0px, screen-reader path and 400% zoom fixture passed.

Resource path

The practical follow-up I would build is an accessible virtualization laboratory with feed and article semantics, roving focus option, stable key model, aria-posinset and aria-setsize policy, overscan rules, variable-height measurement, ResizeObserver batching, anchor compensation, prepend and append loading, focus pinning, route restoration, no-virtualization fallback, assistive-technology matrix, and performance traces. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• What performance problem exists now?
• What key survives refresh?
• Is this truly a feed?
• Can scrolling evict focus?
• Which keys move between items?
• What invalidates a measurement?
• Which item anchors the viewport?
• Which cursor is in flight?
• Which item was the user reading?
• Is position announced correctly?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For large feeds that reduce DOM cost without making content position or keyboard access fictional, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• bounded layout work and stable estimates across representative content
• the same item and visual offset remaining stable through prepend and resize
• one ordered page per cursor with bounded requests and recoverable errors
• back navigation returning to the intended item within a measured tolerance
• DOM, interaction, and restoration budgets holding in representative workflows

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• The logical feed outlives the DOM window.
• Loading and measurement must preserve an anchor.
• Some tasks should not be virtualized.
• A trace connects performance to navigation quality.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to activity streams, recruiter inboxes, audit logs, social timelines, search results, and monitoring views that may contain thousands of variably sized items while keyboard, screen-reader, zoom, find, focus, and scroll behavior still need a coherent document: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through a windowed feed architecture that keeps semantic item identity and position stable, moves a rendering window around focus and viewport, measures variable height without jumps, loads in both directions, restores anchors, and falls back when virtualization harms the task. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

An accessible virtualized feed is a hiring signal because it shows I can connect rendering performance, DOM semantics, focus, layout measurement, asynchronous pagination, product navigation, and assistive-technology testing without sacrificing one discipline to another.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.