Skip to main content
Cornell University

Cornell Design System Documentation

Custom Development Team

  • Home
  • Template Structure
    • Template Structure Overview
    • Band (Layer 1)
    • Region (Layer 2)
    • Container (Layer 3)
    • Layout (Layer 4)
    • Section (Layer 5)
    • Block and Content (Layer 6)
  • Landmarks
    • Landmarks Overview
    • Footer
    • Header
    • Main content
    • Navigation
  • Components
    • Components Overview
    • Blockquote
    • Button
    • Checkboxes
    • Fieldset
    • Form inputs (other)
    • Form inputs (text)
    • Horizontal rule
    • List
    • Panel
    • Table
  • Patterns
    • Patterns Overivew
    • Accordion
    • Card
    • Tablist
  • Typography
    • Fonts
    • Headings
    • Icons
    • Images
    • Text and color
  • Development
    • Development Overview
    • Filters

On this page

  1. Code
    • Full Tabpanel
  2. Sub components
  3. Functionality
    • Cursor or touch input
    • Keyboard input
    • Screen reader/other assistive technology input
  4. Classes
    • {tabs-style}
    • {tab-size}
  5. Accessibility Expecatations

Tablist

A tablist is a user interface pattern that displays one content panel at a time. Users can switch between panels using tab buttons. Hidden panels remain inaccessible to assistive technologies until their corresponding tab button is activated.

Appropriate uses of a tablist include

  • Categorizing and/or grouping content in distinct sections while reducing the amount of clutter on the page.
  • Limiting the amount of instructions or options visible at one time where a user typically doesn't need to reference content hidden in other tabs frequently (or at all).

Do not use a tablist when there are

  • Large chunks of content: If the amount of content is large, consider using accordions instead or moving this content to its own page.
  • Critical/Frequently referenced information: If the content is important for users to quickly refer to, do not hide it in a tabpanel.
  • Dynamically updating content: If the content updates dynamically (especially on its own), do not put this content in a tabpanel which can be hidden.

Code

Full Tabpanel

You must have the cds.js script loaded for the tabpanels to work.

<div class="ui-tabs {tabs-style}">
    <div role="tablist" aria-label="All Tabs (Change this in your production site)" class="{tab-size}">
        <div class="container">
            <button class="button" role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1" tabindex="0">Tab Button 1</button>
            <button class="button" role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1">Tab Button 2</button>
        </div>
    </div>
    <div id="panel-1" role="tabpanel" tabindex="0" aria-labelledby="tab-1">
        <h2>Content 1</h2>
        <p>This content area can be filled with WYSIWYG content.</p>
    </div>
    <div id="panel-2" role="tabpanel" tabindex="0" aria-labelledby="tab-2" hidden="hidden">
        <h2>Content 2</h2>
        <p>This content area can be filled with WYSIWYG content.</p>
    </div>
</div>
Tabpanel Demo

Content 1 Heading

This content area can be filled with WYSIWYG content. Use the correct heading level based on the rest of content

Content 2 Heading

This content area can be filled with WYSIWYG content. Use the correct heading level based on the rest of content

Sub components

  • Tablist: The group of tabs (similar to a <fieldset> or radiogroup role, this wrapper contains all the tabs).
  • Tabs: The buttons which are used to toggle the visible tabpanel. These are typically arranged inline, side by side.
  • Tabpanel: The individual panels of content of which only one is selected and visible at a particular time.

Functionality

Cursor or touch input

Clicking or tapping on a tab will reveal the tabpanel that is associated with the tab. The other tabpanels will be hidden. The tabpanel contents can contain any other flow content (text, images, inputs, etc..)

Keyboard input

A user will initally use the Tab key to target the tablist (not individual tabs). The tablist needs to have a focus indicator. The arrow keys will be used to switch the active tab. The next press of the Tab key will move the user's focus into the active tabpanel and ignore all of the contents in the hidden tabpanels.

To accomplish this, tabs that are not the "active/selected" tab will have the attribute tabindex="-1" applied to them. Javascript is used to handle the arrow keys swapping between the tabs, which will toggle the tabindex values as well between 0 and -1.

Screen reader/other assistive technology input

A user will follow the same control pattern as Keyboard input, however they will also have more information communicated to them. Assistive technology will communicate the accessible name of the tab that is active, then it will communicate the name of the tablist that the tabs are part of.

When assistive technology moves into the tabpanel, it will announce the name of the tabpanel (which should match the cooresponding tab name), and that it is a tabpanel. Content inside will follow the conventions of normal flow content (headings, text, images etc...).

Classes

{tabs-style}

Defines the style of the tablist.

Class Style
Default (not recommended) Because the tabs are buttons, they will take on the style cues of a normal button including default margin and padding.
.tabs-navbar The tabs will take the appearance of transparent buttons with a red underline underneath the active tab.
.tabs-classic The tabs will take on the default button style cues, except that the margin will be reduced to 1px.
Tabs Style Demo

Content 1 Heading

This content area can be filled with WYSIWYG content. Use the correct heading level based on the rest of content

Content 2 Heading

This content area can be filled with WYSIWYG content. Use the correct heading level based on the rest of content

{tab-size}

Controls the appearance of the tabs. The classes here are determined by the button component.

It's recommended to only use the button-size or button-color options.

Accessibility Expecatations

Modality Description Criterion
Keyboard Tablist and tabs must be keyboard focusable. 2.1.1
Keyboard Tabs are navigable using arrow keys. 2.1.1
Keyboard Active tabpanels must be navigable with the keyboard 2.1.1
Keyboard Inactive and hidden tabpanels may not receive any keyboard focus. 2.4.7
Visual Active tab must have a clear visual indicator (non-color alone). 1.4.1
Visual Focusable elements in tabpanel must have a 3:1 contrast ratio with adjacent colors. 1.4.11
Screen Reader Tablist must have role="tablist". 4.1.2
Screen Reader Tabs should be buttons. 4.1.2
Screen Reader Tabs must have role="tab" and aria-controls referencing the corresponding tabpanel. 4.1.2
Screen Reader Tabpanels must have role="tabpanel" and aria-labelledby referencing the corresponding tab. 4.1.2
Screen Reader Tabs must have aria-selected="true" when active, aria-selected="false" when inactive. 4.1.2
All Users Tablist and tabs should have clear visual labels. 2.4.6
All Users The relationship between tabs and tabpanels should be visually clear. 1.3.1

Footer Content

This documentation for CDS was built using MkDocs.