Architecting decoupled but linked Tabs components

WHAT THIS TESTS Whether you understand that functional linkage between components comes from shared state, not DOM adjacency, and whether you can keep accessibility intact when parts are separated.

A GOOD ANSWER COVERS Use a compound component backed by a context provider. A Tabs root renders a provider that owns the active tab value, an updater, and a registry of tab ids. TabList and each TabPanel consume that context, so they can live anywhere inside the provider regardless of layout position. Because the provider can wrap a large region, the TabList in the header and the panels in the main area share one context. Generate stable ids so each tab sets aria-controls to its panel and each panel sets aria-labelledby to its tab, plus roles tablist, tab, and tabpanel. Support controlled and uncontrolled value.

COMMON WRONG ANSWERS Claiming the parts must be siblings or wrapped in a single contiguous container. Prop-drilling the active index through unrelated layout components. Using global mutable state or a singleton that breaks with multiple Tabs instances. Forgetting keyboard navigation and aria relationships once the pieces are physically separated.

LIKELY FOLLOW-UPS How do you support multiple independent Tabs instances on one page? How do you handle keyboard arrow navigation and roving tabindex? Controlled versus uncontrolled? How do you scope the context to avoid collisions?

ONE CONCRETE EXAMPLE Render Tabs as the provider near the top of the page. Inside it, place TabList in the header slot and the TabPanels in the main slot. Clicking a tab updates context active value; the matching panel in the content area renders. No layout component between them passes any props, and screen readers still announce the correct tab-to-panel relationship via shared ids.