Tabs

Tabs allow users to move between different views of related content without leaving the current page. A tab strip includes at least two tabs. Only one tab is actively engaged at a time and is differentiated from inactive tabs by a colored indicator either on the top or bottom edge of the tab, depending on the variant. Tab strips can cover the full width of the page or be limited to content areas within components such as dialogs, cards, and drawers.

Also known as: Tab, Tabstrip, Tab bar, Tab set
Salt package@salt-ds/core
Code

Best practices

You need to check and test any focusable elements included in the tab content.

Keyboard interactions

KeyFunction
Tab
  • If focus is on outside of tabs, Tab enters focus into tabs.
  • If focus is on a tab item, Tab exits the tab component and place focus onto the next element within the tabbing order.
Shift + Tab
  • If focus is inside a tab component, this action moves focus to the previous element in the tabbing order.
Enter / Space
  • If focus is on tab hover state, this action selects a tab item.
Left arrow / Right arrow
  • This action moves focus between tab items in tab bar.
Up arrow / Down arrow
  • This action moves focus between tab items in an overflow menu list.
Home
  • If focus is on a tab, Home moves focus to the first tab.
End
  • If focus is on a tab, End moves focus to the last tab.

Accessibility considerations

Certain ARIA roles must contain particular children (aria-required-children)

Issue context

This aXe issue is flagged when using nested action buttons within tabs. This example follows the W3C's experimental "Tabs with Action Buttons" example and maintains expected keyboard and screen reader interaction patterns Digital accessibility guidance continues to evolve as new design patterns and component challenges emerge. While we have worked to align with existing guidelines, some complex interactions and modern UI patterns present unique accessibility challenges that current guidelines may not fully address. We have implemented solutions that we believe create the most understandable and accessible experience possible, even when they conflict with current automated testing tools.

Support and contributions

We welcome feedback and alternative approaches to addressing any of these accessibility considerations. If you have suggestions for improving these components, please reach out to our team as we are committed to continuous accessibility improvement of our user experiences.