Select your language
Select other languages

Automatic translation

Loading translator…

Magoomake your components work correctlyBack to homepage

Tabbar

A bar providing access to an interface's main areas, with a current destination indicator and consistent navigation.

For working examples and design patterns for this component, see the references tab (opens the references on this page).

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 for persistent access to the interface’s main areas. Define whether items navigate to destinations or switch panels.

What to draw

Show short labels, the current area, focus, and counts when present. The bar must not cover content or controls.

How it behaves

For web destinations, Tab moves through links and Enter navigates. For panels, use the tabs pattern with arrows and manual or automatic activation according to context.

What to document in Figma

Record the chosen pattern, destinations, selection, and focus after changes. Preserve progress and respect safe areas and the virtual keyboard.

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 a Tabbar: a persistent bar providing access to an interface's main areas.

Define whether items navigate between destinations or switch content panels. This choice determines semantics, keyboard navigation, and focus management.

Designing for "no interaction"

  1. Do main destinations have short, understandable labels in addition to icons?
  2. Can you identify the current area without relying solely on color?
  3. Do order and destinations remain consistent across interface areas?
  4. Does the item count allow each destination to be recognized and reached without truncated labels?

Designing for mouse use

  1. Does each item provide a clear click area and interaction feedback?
  2. Does the chosen item lead to the expected destination without confusing navigation with actions such as save or delete?

Designing for gesture use

  1. Does the touch area allow selecting a destination without activating a neighboring item?
  2. Does the bar respect device safe areas and avoid covering content, focus, or controls?
  3. Does the interface remain usable with zoom, rotation, and the virtual keyboard?

Designing for keyboard use

  1. Is focus visible and does its order follow item presentation?
  2. Does navigation use native links or a tab set with commands consistent with the chosen behavior?
  3. After changing destinations, do focus and feedback allow the task to continue?

Designing for screen reader use

  1. Does the bar have a name identifying its purpose?
  2. Does each item communicate its name and the current destination or selected tab?
  3. Are badges, such as new item counts, understandable without relying solely on appearance?

Interaction methods

Mouse interaction

  1. Clicking an item opens the corresponding destination and updates the current area indicator.
  2. In the link pattern, preserve native behaviors such as opening a destination in another tab.
  3. When selecting the current area, avoid unexpected reloads or resets; additional behaviors need to be predictable and documented.

Gesture interaction

  1. Tapping an item provides access to its corresponding area.
  2. The selection indicator updates and the bar remains consistent across destinations.
  3. Additional gestures may supplement navigation while keeping each destination available through an explicit control.

Keyboard interaction — navigation between destinations

  1. In a web Tabbar that navigates between pages or routes, Tab and Shift + Tab move through links in interface order.
  2. Enter activates the focused link. Do not require Space for links or intercept arrow keys as though they were tabs.
  3. When changing routes without reloading the page, update the title and position focus at a logical destination, such as the heading or start of content.

Keyboard interaction — panel switching

  1. When the component actually switches panels on the same page, apply the tabs pattern: Tab enters through the selected tab and then leaves the set for the next element in the sequence.
  2. Right Arrow and Left Arrow move focus between horizontal tabs, including wrapping from last to first and vice versa.
  3. With manual activation, Enter or Space displays the focused tab's panel. Automatic activation is appropriate only when the panel appears without noticeable delay.
  4. Home and End may move focus to the first and last tabs. This behavior is optional and should be consistent.
  5. Update aria-selected and the panel association; focus remains on the tab after selection, and Tab allows moving on to the content.

Keyboard (or gesture) interaction + screen reader

  1. For web navigation between destinations, identify the navigation region, each link's name, and the current area through aria-current="page".
  2. For panel switching, identify the set as tablist, each control as a tab, and the panel as tabpanel, with appropriate labels and associations.
  3. In native applications, use the semantics and commands provided by the platform for the bar and its items.
  4. With a mobile screen reader, navigate items using platform gestures and double-tap or use the activation gesture to open the destination.

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 or application containing a Tabbar

Keyboard navigation — destinations

  1. WHEN I use Tab key to move focus to a Tabbar link
  2. The focus I SEE is strongly indicated visually
  3. THEN, when I use Enter to activate the link
  4. I SEE the corresponding area and the current destination indicator updated
  5. AND I perceive that focus allows continued navigation in the new content
  6. WHEN I use Tab or Shift + Tab, I SEE that I can move through links without trapping focus in the bar

Desktop screen reader

  1. WHEN I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use Tab to focus a navigation item
  2. I HEAR the destination name, identification as a link or equivalent native control, and the current area indication when applicable
  3. THEN, when I activate the item with the appropriate platform command
  4. I HEAR or perceive that the corresponding area opened and I can continue navigating the content

Mobile screen reader

  1. WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus a navigation item
  2. I HEAR the destination name, identification as a link or equivalent native control, and the current area indication when applicable
  3. THEN, when I double-tap or use the appropriate gesture
  4. I HEAR or perceive that the corresponding area opened and I can continue navigating the content

Panel switching on the same page

  1. WHEN the Tabbar is implemented as a tab set and I use Tab to enter the set
  2. I SEE focus reach the selected tab
  3. THEN, when I use Right Arrow or Left Arrow
  4. I SEE focus move between tabs
  5. AND, with manual activation, when I use Enter or Space, I SEE the corresponding panel
  6. WHEN I use a screen reader, I HEAR the tab name and its updated selected state
  7. AND I can move on to the panel content with Tab

Mouse or touch interaction

  1. WHEN I click or tap an item in the bar
  2. I SEE the corresponding area and current area indicator
  3. AND I SEE that the bar does not cover content or controls needed to continue the task

Considerations

  1. Navigation Tabbars and content tabs may look similar but behave differently. Do not use tablist merely because links are aligned in a bar.
  2. On the web, use links for navigable destinations and aria-current="page" for the current one. Use the tabs pattern and aria-selected when switching panels on the same page.
  3. Keep the number of main destinations small. The count and position should follow the context and the chosen platform's recommendations.
  4. Do not use the bar for isolated actions such as saving, deleting, or submitting a form.
  5. Keep labels visible whenever possible. If only icons are used, provide accessible names and assess whether their purpose is recognizable. Prefer Material Icons in web examples.
  6. Hide decorative icons from assistive technologies. Informative counts and badges need accessible meaning and should avoid duplicate announcements.
  7. Do not rely solely on color to indicate the current destination; combine text with a perceptible visual indicator.
  8. If the bar is fixed, reserve space in the content and respect platform safe areas. Check focus, zoom, and the virtual keyboard.
  9. Route changes need to update title, focus, and navigation history according to the flow. Avoid clearing data or progress when switching areas.
  10. Native Apple and Material patterns use their platforms' own resources. Adapt web examples to the component's purpose and verify behavior with assistive technologies.

References

Design patterns

Design System

Original content by Marcelo Sales, initially used in the AccessBoost course (external link - opens in a new window). These interactions represent standard industry patterns, but may be customized in specific cases, provided there are sufficient instructions for people to understand the behavioral change.