Tabs

Tabs are used for displaying grouped content. This pattern allows a user to switch between related pieces of content while retaining the main context and illusion of being at a single location on the site. Sometimes used as a "filter".

Example

See the Pen Tabs by SHC-FED (@SHC-FED) on CodePen.0

Design Specs

  1. Tab height is 36px and each tab has 1px side bar, color #aaaaaa.
  2. 2. Active tabs have a 3px top bar, color #005ccc. The text is Open Sans Semibold, size 15px, color #001733 (font-color-primary). Tabs on Desktop and tablet have a 20px padding on left and right of the text.
  3. Inactive tab tabs have a 1px top and lower bar, color #aaaaaa. The text is Open Sans Regular, 15px, #005ccc (font-color-action).
  4. Hover tabs have a 3px top bar #001733 (font-color-primary). Text styling is the same as inactive tab text styling - Open Sans Regular, 15px, #005ccc (font-color-action).
Not pictured:
  1. The lower bar should extend to match the length of the content area below the tab area.
  2. Tabs on mobile have a reduce left and right padding around the text of 10px, in consideration of the smaller device size.


Note: Design specs are for reference only. Developers should implement patterns using the Enterprise Framework whenever possible - see the Example section on this page.

Production Examples

  • Sears
  • Kmart

Mobile

An example of tabs on Sears PLP, mobile.

Desktop/Tablet

An example of tabs on Sears PLP, Desktop.

Desktop/Tablet

An example of tabs on Kmart PLP, Desktop.

When Do I Use This?

Tabs can make efficient use of screen real estate. They are effective because the controls are familiar and because it forces content to be organized in a high-level, user-friendly manner.

Use tabs when a user would alternate between related content or views (not to navigate to different unrelated areas). Other patterns to consider: breadcrumb, buttons, links.

Do not use tabs if users need to simultaneously see or compare the info behind different tabs. Do not use as progress indicators

Usage Guidelines

1. Position

Position the row of tabs on top of the page or module — not on the sides or the bottom where users would often overlook them.

An example of correct tab positioning.

An example of incorrect tab positioning - a row of tabs must always be at the top of a page or module.

An example of incorrect tab positioning - a row of tabs must always be at the top of a page or module.

2. Form a Single Row

Use only one row of tabs.

"Multiple rows create jumping UI elements, which destroy spatial memory and thus make it impossible for users to remember which tabs they've already visited. If you need more tabs than will fit in a single row, simplify the design, or use another design solution". (source below)

3. Default State

Always have one tab selected by default.

One tab must always be selected, and its associated content displayed.

4. Labels

Tab label content matters. Labels should be succinct, between 2-3 words, and be written in plain language. This ensures multiple tab labels are easy to read, scan and compare. No "marketing speak".
Capitalization - Title Case.

A good example of tab labels.

Long tab labels are difficult to scan and compare. Also, labels should be Title Case .

ADA Compliance

Tabbed elements present multiple challenges for individuals with disabilities. All issues relating to page tab groups can be addressed with a relatively small number of code changes by the developer. In addition to providing information about the state and type of the tabs, developers should provide functionality for denoting the end of tabs. Source

Ideally, when someone using a screen reader opens a new tab, instead of the keyboard focus remaining on the tab title, the tab title acts as an internal page link and positions the keyboard focus in the content of the newly open tab. Source

Sources & Useful links:

Rationale

Tabs on the web use a metaphor/model for paper-based tabs.

SHC rationale: Restyling in 2015 realigned to paper metaphor with stroke above each tab and reduced padding between tabs to support sizing constraints on mobile. The bold non-link text combined with the blue bar is a clear locational cue when compared to other tabs; also, this aligns with our site-wide standard that selected states are blue. All tabs, regardless of state, are clearly readable, and comply with ADA guidelines (e.g. contrast, use text vs images).

Research

Shop My Store / Reserve it

Search Browse "In Store" Tab Functionality & Expectations: The in store feature functioned as shoppers expected; was noticed; no comprehension issues. Caveat: styling different than current Enterprise tab styles.

view full study

State of Experience 2014

Old WCS styling on search/browse - Marketplace Tabs & Notations: Users often miss this feature and complete a transaction without realizing it is not sold by Sears.

view full study

Checkout Redesign- Delivery & Payment Page

Use as progress/breadcrumb was functional, but not easily noticed. Page18

view full study

Tabs, Used right

See 13 usability guidelines for tabs

view article

Surprise points on PDP

Don't try to include too much content. Violates some guidelines above (ex - none preselected). Tabs possibly ineffective for introducing new concepts. Tabs simply not a good solution in this context. see page 7, 10

view full study

When Bad Design Elements Become the Standard

Describes recommended use of tabs: for switching between related/alternative views of the same object/topic/context. Rallies against the use of tabs for navigation (a trend in 1999). See "Navigation Tabs".

view article

Post a New Comment

Your feedback will help us improve this page. If you have a comment about the content of this page, use the form below, and the Patterns Team will get back to you within a business day.

For general questions or assistance, email the Patterns Team directly.