# Tabs

Tabs are a secondary navigation pattern, allowing a user to view only the content they're interested in. They build upon a real world metaphor, and the selected state simulates a folder being physically in front of others in the group.

## Guidance

### When to use

- If you have sub-sections of a page, and there's the need to only show one sub-section at a time.

### When to consider alternatives

- If you have more than four tabs. Consider using a different pattern if your content requires being split into more than four panels.
- If the panel contents can be displayed at once. This will improve the scanability of your page's content and it's more likely the user will be able to find what they're looking for. Typography, including clear section headers, should be enough to allow the user to navigate the page.

### Usage

- Avoid overflowing tabs to new lines. If the tabs can't fit on one row on small screens, consider using utility classes to apply additional responsive styles or use a different pattern.
- Tab labels should be descriptive of their content and set the user's expectations.
- Tab labels should be short — aim for no more than two words.

## Accessibility

- Use anchor links (`<a>`) to create tabs. This allows direct linking, supports progressive enhancement, and preserves default browser behavior like opening tabs in a new window.
  *Note: You’ll need to implement logic to select the appropriate tab based on the current URL.*
- Markup should include proper ARIA roles and attributes to ensure accessibility:
  - **Each tab** (`<a>`):
    `role="tab"`, `aria-selected`, `aria-controls`
  - **Tablist container**:
    `role="tablist"`, `aria-label` (not applied by default — use the `ariaLabel` prop.)
  - **Each tab panel**:
    `role="tabpanel"`, `aria-labelledby`

  When you use our <code>Tabs</code> and <code>TabPanel</code> components together, ARIA roles are handled automatically. The <code>Tabs</code> component sets the appropriate <code>aria-controls</code> and manages selection state, while <code>TabPanel</code> sets its own <code>role</code> and receives a generated <code>tabId</code>. We recommend using both components together to ensure accessibility is correctly implemented.

## Accessibility testing

### Keyboard navigation

- Users should be able to navigate to each tab using the `Tab` key and navigate backwards using `Shift + Tab`.
- Pressing `Enter` should activate the focused tab.
- When a tab has focus, arrow keys (`←`/`→`) should move focus between tabs.
- A visible focus indicator should clearly show which tab is currently focused or selected.

### Screen reader

Our `Tabs` component applies the correct semantic roles (`tablist`, `tab`, and `tabpanel`) to ensure proper screen reader support.
When implemented correctly, screen readers announce:
- The label for each tab which is derived by the `tab` prop on each `TabPanel`.
- Its `role` (e.g., "tab").
- Its position within the set (e.g., "Tab 1 of 3").
- Whether the tab is selected.

### Zoom magnification

To ensure tab content remains visible when the screen is magnified, the widths of tabs and tab panels are defined using percentages. As the page is magnified, the height of the tabs increases and content reflows to fit the new dimensions.

## Learn more

- [How Tabs Should Work](https://24ways.org/2015/how-tabs-should-work/)
- [Simple ARIA tab interface](http://heydonworks.com/practical_aria_examples/#tab-interface)