shadcn.io is not affiliated with official shadcn/ui
Infinite Scroll FAQ Block for React Aria
A FAQ for a library-card app that shows six numbered questions and reveals four more each time a Show more button is pressed, fourteen in all, with a live count.
Installation
Overview
A load-more FAQ for React with React Aria. A centred title and sentence sit over fourteen numbered questions, of which six show at first: the hairline rows run from rail to rail while their content stays on a narrow column, and a button at the foot adds four more each time it's pressed. A polite line beneath the list says "Showing 10 of 14 questions", focus stays on the button as rows appear, and at the end the button turns into a closing line, "That's all 14", with a link for anything else. There is no scroll listener: the button works the same for a mouse, a keyboard and a screen reader. The page's rails and top rule come from the Guides spine, so the block lines up with its neighbours in a stack. It's built from Accordion, Button and Guides, with CSS transitions and your theme's tokens for every colour. For help centres with more questions than a page should open with.
FAQ
How do I change the questions and the batch size?
Edit QUESTIONS at the top of the file: each entry is an id, the question and its answer. FIRST is how many show at the start and STEP is how many each press adds; the total, the count and the numbers beside the rows all come from the list, so a longer one just works. OPEN_QUESTION names the one that's open on load.
Why a button and not scrolling?
A scroll listener that adds rows as you reach the end is invisible to a keyboard, traps the footer out of reach and surprises screen-reader users. A button is a real control: Tab reaches it, Enter or Space presses it, and the polite status line tells a screen reader how many questions are showing now. Pressing it keeps focus on it, so you can keep pressing it, and when the last four arrive it turns into the closing line, which takes focus so the page doesn't jump to the top.
Are the questions that aren't showing yet in the page's markup?
No: only the rows that are showing are rendered, so the first six are what search engines and server rendering see until someone presses the button. If every question must be indexed, raise FIRST to the full count and remove the button, or add structured data built from the same QUESTIONS array.
Within the rows that show, every closed panel stays in the markup as hidden="until-found", so the browser's find in page opens the one that holds a match.
How does it work with a keyboard and a screen reader?
Each question is a button inside its own h3 under the section's h2, and its number is decoration that a screen reader skips. Tab moves from question to question and on to the Show more button, Enter or Space opens and closes a row, and one answer is open at a time.
What moves, and what happens with reduced motion?
The header and list fade up once when the page loads, a row that Show more adds fades in over 300 milliseconds, and the chevron turns as a row opens. With reduced motion the entrance is off, the new rows simply appear and the chevron turns without animating. The catalog's Accordion still eases an answer's height over 200 milliseconds.
How does it fit on a phone?
The rows' content takes the full width less a small margin, so the numbers, questions and chevrons stay on one line where they fit and wrap where they don't, the button sits under the count, and nothing scrolls sideways at 320 pixels. Each press adds four rows, never a long wall at once.