Anatomy of default tab

1. Active tab
   The currently selected tab button that represents the active section of content, it's visually connected to the content container below.
2. Tab indicator
   A visual cue that shows which tab is currently selected, using a horizontal line.
3. Default tabs
   The individual tab buttons that represent each section of content.
4. Leading icons
   Tabs can be labelled as text or icons with text.
5. Tab header
   This is the area that contains all the tab buttons.
6. Tab content
   The area where the content corresponding to the active tab is displayed.
7. Horizontal Scroll button
   This button appears when there are too many tab items to fit in the container. It's used to indicate that there are hidden tabs as well as functionally to assist the user with horizonal scrolling.

Anatomy of section tab

1. Active tab
   The currently selected tab button that represents the active section of content, it's visually connected to the content container below. In section tabs the colour is determined by the tab content container colour.
2. Default tabs
   The individual tab buttons that represent each section of content. In Section tabs the default tab colours are determined by the colour of the previous section to ensure appropriate colour contrast.
3. Previous content section
   Section tabs need to always sit below a content section or header as this is what defines the colour of the default tabs.
4. Tab header
   For consistency it's important the design of the section tab header is exactly the same of default tabs, only the colours of the active and default tabs change.
5. Tab content container
   The tab content container spans the full width of the content container. For this reason, this design isn't recommended to be used on standard content pages that include a left side menu.

Research and rationale

The design of this tab is based on the best practice research for tab design outlined by uk.gov design system and recommendations from the Nielsen Norman Group.

Some of the recommendations included:

• ensuring the active tab is visually connected to the content area and highlighted in multiple ways
• unselected tabs are visually distinct but still clearly clickable
• tabs should include iconography and make use of uniform spacing and padding
• tabs should be designed so they're visually distinct from primary navigation.

Metaphorically, using tabs is like leafing through index cards in a drawer of an old-fashioned card catalogue, so users must be able to tell at a glance what constitutes an "index card" (i.e., tab panel).

Responsive design

Our tab component also incorporates functionality inspired by IBM Carbon for how it responds on mobile devices. We conducted a review of 8 different designs system tab components to find out they dealt with multiple tabs on small screens and found the horizontal scroll option to be the easiest to operate and most familiar.

Other alternatives that were considered were overflow buttons with dropdown menus and vertical stacking. The disadvantages of these options were that the overflow button added interaction costs and vertical stacking pushed content far below the tab menu and made switching between content sections more difficult.

Colours and themes

The tab component builds on existing Design System styles including borders styles and icons and there are options for any background colour.

Development

The tab component requires a couple of javascript functions to work correctly. One to implement the standard tab functionality and another to handle how it responds on mobile.

TBC

Accessible tab requirements

Keep these considerations in mind if you're modifying the Design System or creating a custom component.

Please note there is complexity in terms of ARIA labelling and keyboard control that must be incorporated for accessibility. You can find more information on the W3C Example of Tabs with Manual Activation.

WCAG guidelines

1.4.3: Contrast (Minimum)

Make sure the tab component has sufficient colour contrast between text and background colours. The contrast ratio should be at least 4.5:1 for normal text and 3:1 for large text, ensuring that users with low vision can read the content easily (W3C, 2018).

1.4.4: Resize text

Ensure that the tab component's text can be resized up to 200% without loss of content or functionality, allowing users with low vision to read the content more easily (W3C, 2018).

1.3.1: Info and Relationships

Ensure that the tab component's structure and relationships between elements are clear and understandable. Use correct semantic markup like ARIA roles and properties to convey the purpose and state of each tab and tab panel (W3C, 2018).

2.1.1: Keyboard

Make sure users can navigate and operate the tab component using only a keyboard. Implement proper keyboard navigation, including support for arrow keys to move between tabs, the Enter or Space key to activate a tab, and the Home and End keys to jump to the first and last tabs (W3C, 2018).

2.1.2: No Keyboard Trap

Ensure that keyboard users do not get trapped within the tab component. Users should be able to navigate out of the component using the same means they used to enter it (W3C, 2018).

2.4.3: Focus Order

Ensure a logical focus order for the tab component. As users navigate through the component using a keyboard, the focus order should match the visual order, making the experience predictable and consistent (W3C, 2018).

2.4.7: Focus Visible

Provide a clear and visible focus indicator for the tab component. When a tab receives focus, it should be visually distinct from other tabs, making it easy for users to identify the currently focused tab (W3C, 2018).

4.1.2: Name, Role, Value

Ensure that the tab component's name, role, and current value are available to assistive technologies. Use ARIA attributes to provide appropriate names, roles, and values for each tab and tab panel, allowing screen reader users to understand the purpose and state of the component (W3C, 2018).

Assign appropriate ARIA roles:

• Set the role of the tablist container to "tablist".
• Set the role of each tab item to "tab".
• Set the role of each tab panel container to "tabpanel".

Example:

<ul role="tablist"> <li role="tab">Tab 1</li> <li role="tab">Tab 2</li> </ul> <div role="tabpanel">Content for Tab 1</div> <div role="tabpanel">Content for Tab 2</div>

Set the relationship between tabs and tab panels using the "aria-controls" and "aria-labelledby" attributes:

• For each tab item, add the "aria-controls" attribute with the ID of its associated tab panel.
• For each tab panel, add the "aria-labelledby" attribute with the ID of its associated tab.

Example:

<ul role="tablist"> <li role="tab" id="tab1" aria-controls="tabpanel1">Tab 1</li> <li role="tab" id="tab2" aria-controls="tabpanel2">Tab 2</li> </ul> <div role="tabpanel" id="tabpanel1" aria-labelledby="tab1">Content for Tab 1</div> <div role="tabpanel" id="tabpanel2" aria-labelledby="tab2">Content for Tab 2</div>

Set the "aria-selected" attribute to indicate the current active tab:

• For the active tab, set the "aria-selected" attribute to "true".
• For all other tabs, set the "aria-selected" attribute to "false".

Example:

<ul role="tablist"> <li role="tab" id="tab1" aria-controls="tabpanel1" aria-selected="true">Tab 1</li> <li role="tab" id="tab2" aria-controls="tabpanel2" aria-selected="false">Tab 2</li> </ul>

Ensure that only the active tab panel is visible:

• For the active tab panel, set the "aria-hidden" attribute to "false".
• For all other tab panels, set the "aria-hidden" attribute to "true".

Example:

<div role="tabpanel" id="tabpanel1" aria-labelledby="tab1" aria-hidden="false">Content for Tab 1</div> <div role="tabpanel" id="tabpanel2" aria-labelledby="tab2" aria-hidden="true">Content for Tab 2</div>