composite pattern · Menus and navigation
Tabs
A set of layered sections where a row of labels switches one shared content region, with exactly one panel visible at a time.
Decisive boundary
A tab panel is a container for content, not the content itself. Separate navigation from content switching and ensure only one panel is visible.
Definition and intent
What is a Tabs UI pattern?
Use the behavior, not the silhouette
A set of layered sections where a row of labels switches one shared content region, with exactly one panel visible at a time. The term is used here as a composite pattern made from multiple controls or regions that must work together. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Let users switch between related views or content sections without navigating to another page. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Tabs, the boundary is: A tab panel is a container for content, not the content itself. Separate navigation from content switching and ensure only one panel is visible.
Do not implement it as Accordion when multiple sections remain visible, and Navigation Menu when tabs represent page destinations. If those requirements describe the real task better, use the related pattern page or the full Menus and navigation comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Let users switch between related views or content sections without navigating to another page.
Define opening and closing
Click or keyboard selection of a tab label. Selecting another tab replaces the visible panel; tabs themselves remain visible.
Specify access behavior
Tab list receives one tab stop; arrow keys move between tabs; activation moves focus to the panel or keeps it on the tab per design. Tab enters the list; Left/Right or Up/Down arrows move between tabs; Enter or Space activates; Home and End move to first and last tabs.
Reject the near miss
Accordion when multiple sections remain visible, and Navigation Menu when tabs represent page destinations.
Behavior contract
What must survive the build
- trigger
- Click or keyboard selection of a tab label.
- dismissal
- Selecting another tab replaces the visible panel; tabs themselves remain visible.
- modality
- Non-modal inline structure.
- focus
- Tab list receives one tab stop; arrow keys move between tabs; activation moves focus to the panel or keeps it on the tab per design.
- keyboard
- Tab enters the list; Left/Right or Up/Down arrows move between tabs; Enter or Space activates; Home and End move to first and last tabs.
- interactive
- Each tab panel may contain normal interactive content in document order.
- persistence
- Selected tab state should persist during the page session when useful.
- placement
- Horizontally stacked tab labels above or beside a shared content region.
- mobile
- Tabs may wrap, scroll horizontally, or collapse into a select control on narrow viewports.
Failure modes
Common wrong builds
- Using links that navigate away instead of switching panels.
- Hiding the active tab indicator.
- Failing to expose the tab-to-panel relationship in accessibility.
- Putting more than one tab stop in the tab list.
Observable checks
Verify the result
- Exactly one panel is visible at a time.
- Arrow keys navigate between tabs.
- The active tab is visually and programmatically indicated.
- Each tab panel is correctly associated with its tab.
- Mobile layout remains operable on narrow screens.
Coding-agent handoff
Implementation brief template
Pattern: Tabs Purpose: Let users switch between related views or content sections without navigating to another page. Trigger: Click or keyboard selection of a tab label. Dismissal behavior: Selecting another tab replaces the visible panel; tabs themselves remain visible. Modality: Non-modal inline structure. Focus behavior: Tab list receives one tab stop; arrow keys move between tabs; activation moves focus to the panel or keeps it on the tab per design. Keyboard behavior: Tab enters the list; Left/Right or Up/Down arrows move between tabs; Enter or Space activates; Home and End move to first and last tabs. Interactive content: Each tab panel may contain normal interactive content in document order. Placement: Horizontally stacked tab labels above or beside a shared content region. Mobile behavior: Tabs may wrap, scroll horizontally, or collapse into a select control on narrow viewports. Do not implement as: Accordion when multiple sections remain visible, and Navigation Menu when tabs represent page destinations. Acceptance checks: - Exactly one panel is visible at a time. - Arrow keys navigate between tabs. - The active tab is visually and programmatically indicated. - Each tab panel is correctly associated with its tab. - Mobile layout remains operable on narrow screens.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Tabs UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Tabs in web UI?
A set of layered sections where a row of labels switches one shared content region, with exactly one panel visible at a time. In this reference set it is a composite pattern made from multiple controls or regions that must work together.
When should I use a Tabs?
Let users switch between related views or content sections without navigating to another page. The decisive boundary to confirm is this: A tab panel is a container for content, not the content itself. Separate navigation from content switching and ensure only one panel is visible.
What keyboard and focus behavior does a Tabs need?
Tab enters the list; Left/Right or Up/Down arrows move between tabs; Enter or Space activates; Home and End move to first and last tabs. Tab list receives one tab stop; arrow keys move between tabs; activation moves focus to the panel or keeps it on the tab per design. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Tabs behave on mobile?
Tabs may wrap, scroll horizontally, or collapse into a select control on narrow viewports. Its modality is a separate requirement: Non-modal inline structure.
How do I verify a Tabs implementation?
Start with observable checks: Exactly one panel is visible at a time. Arrow keys navigate between tabs. The active tab is visually and programmatically indicated. Then verify the remaining checks and compare the result with the linked source guidance.