Tabs

Tabs switch between a few peer views in the same context, one panel at a time — settings sections, overview/detail, related lists. Tabs owns the active value and orientation, TabsList holds the TabsTriggers (roving focus), and each TabsContent panel shows when its value is active. Use tabs when the views are siblings the user toggles between; for sequential, gated steps use a Stepper, and for primary site navigation use NavigationMenu.

Tabs are for peer views, not steps or pages. They imply equal, independent sections in one place — don't use them for an ordered flow (that's a Stepper) or to navigate to separate URLs (that's navigation). Keep the set small enough to see at once; many tabs that wrap or scroll signal the content wants a different structure.

Use short, parallel labels and a sensible default. One or two words each, in the same grammatical form, with the most important panel active first. Don't bury a required action inside a non-default tab where users may never look.

Respect the keyboard model. Arrow keys move between triggers and the active panel is wired via aria-controls; don't put the only path to critical content behind a tab a keyboard user might skip. Avoid tabs within tabs.