Tabs

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use to switch content groups on the same page; first consider a simpler presentation.

What to draw

Show the tabs, selected tab, corresponding panel, and keyboard focus indicator.

How it behaves

Arrow keys move between tabs. Define whether navigation opens the panel or Enter or Space is required; Tab allows moving to the content.

What to document in Figma

Record tab-to-panel relationships, activation mode, and wrapping between the first and last tabs.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing interactive components of type Tabs.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

Before interacting, can you visually tell that the component is interactive?
Before interacting, can you visually tell which component in a set is selected?

Designing for mouse use (any pointing device)

Is there visual feedback when hovering over the actionable component?
Is there visual feedback when clicking the actionable component?
When clicking a component in the group, is its corresponding content displayed?

Designing for gesture use

Is there visual feedback when activating the component?
When activating a component in the group, is its corresponding content displayed?

Designing for keyboard use (any non-pointing device)

Is there visual feedback when focusing the component?
With automatic activation, when navigating between tabs, can you perceive the focus change together with the content loading?
With manual activation, when navigating between tabs, can you perceive the focus change?
With manual activation, after navigating between tabs, can you activate the group's content with "enter" or "Space"?
When on the last tab in a set, does continuing navigation move focus to the first item?
When on the first tab in a set, does continuing navigation move focus to the last item?

Designing for screen reader use

When focusing a tab, can you clearly identify the component?
When focusing a tab, can you identify its position in the set (for example, 1 of 4)?
When focusing a tab, can you hear whether it is selected?
When focusing a tab, can you hear whether it is active?
When focusing an inactive tab and activating it, can you hear that it is now active?

Interaction methods

Possible interaction methods for components of type Tabs.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

On hover, each component should provide visual feedback confirming that interaction is possible.
On a mouse click, the component should provide visual feedback confirming the click and display the selected group's content.

Keyboard interaction (any non-pointing device)

When focused with the keyboard, each component should provide visual feedback with a visible focus indicator.
When focus is outside the tab set on a preceding component and the TAB key is pressed, the previously active tab should receive focus.
When focus is already in the tab set with a group activated, pressing TABmoves focus to the first actionable component inside the open group. If there is no actionable component, focus moves to the next actionable component on the screen.
Navigation between the remaining tabs should use the arrow keys eastRight ArrowandwestLeft Arrow.
By default, each group's content loads automatically after using the arrow keys. You can configure content to load only after pressing the "enter" or "Space" key, but this is not recommended.
When the last tab is selected, using the eastRight Arrow key should move focus to the first tab.
When the first tab is selected, using the westLeft Arrow key should move focus to the last tab.

Keyboard (or gesture) interaction + screen reader

When focusing a tab, you can hear its name, position (for example, 1 of 4), and whether it is active.
When focusing other tabs, you can hear the component's name, position, and whether it is active.
When focusing a tab, you can hear that it is a "tab" and belongs to a tab set.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing a set of tabs

Keyboard navigation

WHEN I use the Tab key to move focus to the tab set
The focus I SEE is strongly indicated visually on the active tab
THEN, when I use the arrow keys eastRight Arrow and westLeft Arrow
I SEE focus moving between tabs in the group
THEN, when activation is manual and I use Enter or Space
I SEE the focused tab's panel displayed
THEN, when I use the Tab again
I SEE focus move to the active content panel or its first actionable component

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use the Tab key to move focus to a tab
- I HEAR the tab's name.
- I HEAR that the component is identified as a tab.
- I HEAR its position in the set, when available.
- I HEAR whether the tab is selected.
THEN, when I navigate between tabs and activate one
I HEAR or perceive that the panel corresponding to the selected tab is available.

Mobile screen reader

WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus a tab, the following happens:
- I HEAR the tab's name.
- I HEAR that the component is identified as a tab.
- I HEAR whether the tab is selected.
THEN, when I double-tap to activate a tab
I HEAR or perceive that the panel corresponding to the selected tab is available.

Considerations

Considerations for components of type Tabs.

Responsiveness: This component may be replaced with a more suitable one on smaller screens.
tabs should only be used when other options cannot be used.
Interaction with arrow keys is not always understood by everyone, although it is a design pattern.
People developing screens also have difficulty understanding keyboard interaction patterns, which can lead to incorrect implementations if the documentation is not followed.

References

Additional references for components of type Tabs.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.