Component proposal: Tabs

[tannerbachelor]

Tabs proposal – The United States Web Design System

The purpose of this document is to explain the customer impact the Government Transformation Team’s tab component will have from its implementation into The United States Web Design System (USWDS). The document also provides a demo environment and specs outlining the design of the component.

Introduction

The Government Transformation Team (GTT) at Amazon Web Services (AWS) uses The United States Web Design System (USWDS) as the principal design system in our open-source application, Performance Dashboard on AWS. In lieu of a tabs component included within USWDS, we have designed and developed a tabs component by embracing the inclusive design principles and visual guidance from USWDS to meet the needs and expectations of our public sector customers.

In this document, we explain the user impact of implementing this tabs component into USWDS and highlight practical user needs that support its introduction. We provide the design of our tabs component; including code, a working demo environment, and research that supports the validity of its design. In doing so, we hope to prove this tabs component will meet the needs and expectations of customers by being implemented into The United States Web Design System.

User impact

The impact to users from the implementation of this tabs component can be categorized into two groups. The first group are those who design and develop public facing experiences with the help of USWDS and its open-source design system. We refer to this group as ‘builders’. These are professionals like Software Development Engineers, Solutions Architects, UX Designers, Visual Designers, Product Managers and more. The second group is the ‘end-user’ or ‘end-users’. These are the people who will use and interact with the experiences built using USWDS. These people are the real humans, the citizens of all abilities who deserve and expect accessible experiences that work for them when they interact with their governments and digital public-facing services.

Builders using USWDS know that the experiences they build for citizens need to work and behave like the experiences these citizens use on other websites and apps throughout their lives. This is known as Jakob’s Law of UX. It states: “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.” The experiences that have yet to be built using USWDS need to leverage components that citizens use on other websites they know and love. This means having the ability to use components that behave the way they expect them to, that allow them to complete tasks and make actions the way that is easy and familiar to them. Including a wide range of components will empower builders using USWDS with a component toolkit readily available to them to build the citizen facing experiences of tomorrow.

Builders also know time is of the essence when building these experiences. They may sense an immediate need for including as many familiar components as possible to solve problems within large-scale products and services provided by the U.S. government. On December 13, 2021, U.S. President Joseph R. Biden signed an Executive Order titled “Transforming Federal Customer Experience and Service Delivery to Rebuild Trust in Government”. Its purpose, at its core, is to re-build trust in government by improving the experiences the citizens of the United States use to interact with their government. Named in this Executive Order are 17 federal agencies who are called upon to deliver these improved experiences through IT modernization and human centered design. These agencies include the State Department, Treasury Department, Interior Department, Agriculture Department, Education Department, Office of Veterans Affairs among several others.

A tabs component will also provide builders benefits in time and money. By providing a readily available tabs component within the USWDS, builders will no longer need to spend time to seek out third-party open-source design system components that will fulfill their user needs and expectations. Additionally, an available tabs component will eliminate the costs accrued to design, develop, test, and implement a custom component; saving time and money that can now spent developing public serving applications. USWDS will be able to provide further guidance on when builders should use tabs, when to consider something else, and additional support by including a component overview page as seen with other components within the library. To help facilitate the introduction of this tabs component, we have included a draft of what may be included in a tabs overview page in this proposal. (See Tabs – Component overview.jpg.zip).

The agencies listed above are a subset of a larger audience of builders and end-users who either currently rely on USWDS, or will rely on USWDS in the future to modernize their experiences. No matter the agency, or public sector entity, each will have user journeys and personas that map out key tasks they will want to solve for their end-users.

In a reimagined experience on va.gov, a veteran relying only on their keyboard will be able to use tabs to compare their healthcare overview from 2022 to the previous year the same way a mouse and keyboard user would.

A farmer in rural Ohio who relies on a screen magnifier and a screen reader can identify the farm loan program they are looking for which has been labeled by tabs and are properly displayed and functional when zoomed in at 400%, and read by a screen reader.

The executive order alone has the potential for a large-scale user impact – yet it only represents a subset of users who rely on USWDS to provide experiences to their end users. The true impact to the end user of a USWDS tabs component built by federal agencies, private and public sector builders who are tasked with designing a better experience for the citizens they serve is endless.

Design

The constructed design file can be found in provided file titled ‘Tab – Design Demo.fig.zip’

Component code

<div
  role="tab"
  class="tab-style display-inline-block padding-x-2 padding-y-105
         text-bold font-sans-md"
  tabindex="0"
  aria-label="Active Section Tab label" 
  style="cursor: pointer; white-space: nowrap;"
>
Tab label
</div>

The tab-style css class has three states:

1. Unselected/Inactive
The state a tab displays when it is not selected, or showing content.

.tab-style {
  @include u-text("base", "!important");
  background-color: transparent !important;
}

2. Selected/Active
The state displayed after a user has clicked or tapped a tab which displays only the content belonging to the tab selected.

.tab-style-active {
  @include u-text("base", "!important");
  background-color: transparent !important;
  border-bottom: 3px solid color("base-dark") !important;
}

3. Hover
Displayed when a user is hovering over the selection area.

.tab-style:hover {
  @include u-text("base-dark", "!important");
  background-color: transparent !important;
}

Component preview
To preview the tabs component live in any browser, use this link. Or copy this link into your browser: https://demo.badger.wwps.aws.dev/fire-safety-and-emergency-medical-services.

Accessibility

Flows that use our tab component were audited and accessed against WCAG 2.1 guidelines. These audits identified accessibility barriers for users with cognitive disabilities, low vision users, and keyboard only users. The results of these tests have concluded the application and tabs component to be WCAG 2.1 compliant.

Accessible design included in component:

• Tabbing to highlight active state
• Aria-label for screen reader to indicate each tab is a ‘tab panel’, and its name
• Aria-label indicates if currently selected is the ‘active tab panel’
• Keyboard interaction: Pressing Enter select the active, highlighted tab panel
• Arrow key tab functionality
• Hover state used as a signifier

WCAG References

1.3.1 Info and Relationships (Level A)
Understanding Info and Relationships | How to Meet Info and Relationships

4.1.2 Name, Role, Value (Level A)
Understanding Name, Role, Value | How to Meet Name, Role, Value

2.1.1 Keyboard (Level A)
Understanding Keyboard | How to Meet Keyboard

2.1.3 Keyboard (No Exception) (Level AAA)
Understanding Keyboard (No Exception) | How to Meet Keyboard (No Exception)

Contributors

Mazen Kharbutli, Software Development Engineer, AWS
Miguel Abreu, Software Development Engineer, AWS
Tanner Bachelor, User Experience Designer, AWS

Additional context

Tabs – Component overview.jpg.zip
Tabs – Design Demo.fig.zip

[bonnieAcameron]

Hi Mazen, Miguel, and Tanner,

Thank you so much for contributing this Tabs component proposal to the design system. This is thoughtful and thorough work. We discussed this component during a team meeting, and had a few follow-up questions. Specifically, we want to work with you to understand the guidance aspect to this component as much as the technical side.

We try to take a guidance-driven approach to component development, so let's take a step back and try to answer some of the fundamental questions about tabs from a guidance perspective:

• Most critically: When should users use the Tabs component? When should they consider something else?
• Are there any caveats you'd put on the use of Tabs?
• What harm might using Tabs introduce?
• What type of user might be at risk for tabbed content?
• What type of user is most likely to get the most from tabbed content?
• In which cases should teams use Tabs instead of another USWDS component?
• Is there a usability gap that other components are not filling?
• What have you learned about the usability of Tabs that's important for our audience to understand? For instance, is there a maximum number of recommended tabs in a single element?
• How might a team use tabs badly?
• Are there components that should not be combined with tabs? Any that are a particularly good match?

As our team has learned with the Accordion component, there is a usability cost when a component hides content from the user. For instance, as with Accordion, a search engine result might point to content that's hidden in a tab and then isn't easily findable in an in-page search. In general, hiding content behind an interaction can add complexity. Complexity has a cost for all users, particularly those with physical or cognitive disabilities. It's important for us to understand how and why to use tabs, and how and when the benefits of using tabs outweigh these costs.

We’re looking forward to hearing your thoughts on these questions. Thanks for helping us think through the guidance!

[tannerbachelor]

Hello Bonnie,

Thank you for your response. We're happy to answer the following questions with you and the team, and welcome any further discussion or call to clarify the usage and guidance of the tabs component.

• Most critically: When should users use the Tabs component? When should they consider something else?

  • When to use Tabs
    • If you need to organize and group different blocks of content.
    • If you are adding a small to moderate amount of content within tabs.
  • When to consider something else
    • If you are organizing a large amount of disparate content.
    • If you need more than one group of hidden content on a page to display at once, consider the ‘Accordion’ component instead.

• Are there any caveats you'd put on the use of Tabs?

  • Allow entire tab area to be selectable. Allow users to click or tap anywhere in the label area to open a tab and view its content.
  • Tab label must allude to content nested within tab as concise as possible. Limit label to few words.
  • Enable accessible horizontal scrolling in a single row to accommodate limited horizontal viewports.
  • Place tabs at the top of the module or element where the content is being grouped. Fix to top of viewport as necessary.
  • Do not use favicon or icons in tabs.
  • Use similar punctuation between each tab.

• What harm might using Tabs introduce?

  • Using tabs introduces limited harm for users. While most potential harm is linked to misuse of the component, other harm may involve mislabeling tabs that would cause users to miss information nested within hidden components.

• What type of user might be at risk for tabbed content?*

  • A tabs component implemented without accessibility considerations may put keyboard-only users at risk of missing or not being able to access content nested within subsequent tabs.
  • Any user dependent on ARIA labels to find content might be at risk of finding content if labels are not properly labeled.

• What type of user is most likely to get the most from tabbed content?

  • Users who have difficulty comprehending large quantities of information at once, or people with learning disorders such as dyslexia may benefit the most from tabbed content. These users will be able to select specific tabs and choose what to read without having to scan the entire content of a page at once.

• In which cases should teams use Tabs instead of another USWDS component?

  • If your use case involves a user needing to digest smaller amounts of information at one time, use tabs.
  • If your use case involves building a FAQ or different blocks of content that may need to be shown at one time, use the 'Accordion' component.

• Is there a usability gap that other components are not filling?

  • An Accordion offers vertical grouping of disparate, unrelated content that allows more than one group of content to be opened at once. There are a few gaps that a tabs component fills.
    • Horizontal grouping of related information.
    • Offering users the ability in place while alternating between two or more groups of related content.
    • User familiarity and expectations of a tab functionality is not present within any other component.

• What have you learned about the usability of Tabs that's important for our audience to understand? For instance, is there a maximum number of recommended tabs in a single element?

  • To ensure the operation of a tab is predictable, ARIA design pattern for tabs (https://www.w3.org/WAI/ARIA/apg/example-index/tabs/tabs-manual.html) is recommended.
  • You should limit grouping to 7 tabs in a single element. Using a long grouping of tabs requires significant horizontal scrolling in a smaller viewport, and increase cognitive load for users.
  • Ensure ARIA labels allude to tab label and content within tab.
  • The tab list should have an aria-label and contain the buttons marked-up with the role of ‘tab’.
  • The tabs should have an ‘aria-controls’ attribute referencing the id of the corresponding tab panel.
  • The aria-selected attribute can be used to indicate the selected tab.
  • The role of ‘tabpanel’ should then be used with an ‘aria-labelledby’ referencing the corresponding tab.
  • Users should be able to move focus between tabs using the arrow keys on keyboard.

• How might a team use tabs badly?

  • A team may mistakenly use tabs as a means of site-level navigation. Tabs should be used only for relating relative content within a page or module.
  • A team may mistakenly use tabs as a means to compare content between tabs.

• Are there components that should not be combined with tabs? Any that are a particularly good match?

  • In general, tabs should be paired with content-driven components like text, images, or data visualizations.
  • Avoid combining tabs with other components that nest content. For instance, adding an ‘Accordion’ inside of a tab’s content should be avoided.
  • Tabs should be used to group content. It is not recommended to place other highly interactive components within a tab, or components that are task-driven like forms, data entry, or page-level alerts.

_

Building accessible experiences is the top priority of our team. The decision to develop a tabs component that met the needs of our customers outweighed the complexities that would be introduced to the experience. We leaned on our research to address these complexities. Specifically, for people living with cognitive or physical disabilities who will interact with the tabs component. JAWS and NVDA users find it helpful if all expandable components like accordions and tabs announce their element type (with descriptive naming conventions that allude to the content nested inside of them) to save confusion and enable the element to be predictable, and understood.

While content nested within tabs can be found in most search engine results, finding this content within a page using keyboard find functionality can prove difficult for some users. This complexity can be alleviated with an in-page search present on pages with tabs that users can use to search for content that may be behind components like an ‘accordion’ or ‘tab’. Furthermore, we recommend (as shown in our guidance for usage) to ensure tab labels allude to the content nested within (much like an ‘Accordion’), which will help fill a usability gap that may come along with users visiting a page with tabs and any other component that nests content.

[mgifford]

I'd love to have a Tabs component. I do not know how well that ARIA example is being tested or maintained. Usually the W3C is great, but updates are hard for everyone. I think that the https://design-system.service.gov.uk/components/tabs/ model is a good one to start with. Just not sure how it differs from what you've proposed.

[mejiaj]

@tannerbachelor thanks to you and your team for providing those answers!

Sorry if I missed this, but I'm curious.

1. What accessibility testing or criteria was involved when creating this component? Was there a specific WCAG level you aimed for?
2. There's a lot of divs used. Was this a conscious choice over more semantic HTML elements?

[tannerbachelor]

1. Accessibility tests conducted by both an internal and external accessibility team (AWS & Digital Accessibility Centre, respectively) gave us advise on how to design the component to be more accessible to our users. In both instances, flows involving the use of our tabs component were given to users for specific task completion. Those who completed these tasks included people with cognitive disabilities, people with visual impairments, people who use voice activation, and people who only use a keyboard to navigate. Our WCAG level goal is [AAA]. Currently, we recognize our tabs as being WCAG [AA] compliant.

2. Our accessibility audits indicated that our initial use of semantic HTML provided an inconsistent experience when addressing accessibility needs of some users. For low-vision users who require a zoom up to 400%, some tabs would appear off-screen even at large viewports, rendering the component unusable. To address this, we implemented a horizontal scroll and ultimately wrapped tab items in divs top to bottom to provide an experience that was more consistent than what we were able to achieve using list items within lists.

We recognize the trade-off. Using semantic HTML provides predictable use for many users, and can tell them what is in the list – but has inconsistencies when being able to scroll horizontally. We can foresee a tabs component with a horizontal scroll tab list with a more predictable semantic markup to close the gap on the accessibility trade-off while addressing the needs for all of our users.

[mgifford]

@tannerbachelor WCAG 2.0, 2.1 or 2.2?

[tannerbachelor]

WCAG 2.1

[mejiaj]

Hey @tannerbachelor, we're using this proposal as a method for testing and improving our contribution guidelines. This is a goal for the next few months.

Apologies if it's slow, but we want to make sure we're asking the right questions and this component meets all the requirements. We're going to carefully review the responses between the team and check against existing internal process docs. I'll update here as soon as I have more information.

[tannerbachelor]

Hello @mejiaj, just checking in for an update in regards to the status/ progress of the Tabs component implementation. Any information would be helpful for myself and the team. Thank you!

[mejiaj]

@tannerbachelor we're doing research and working on refining a component acceptance framework. uswds/uswds-team#240

I don't have any updates specific to tabs at the moment, sorry.

[tannerbachelor]

Thanks, James. I'll keep an eye out for updates on the framework. I'll also note: we've made additional accessibility enhancements that are reflected in the original demo environment we've provided in the proposal.

Update 4/7/2023: Our demo environment featuring the tabs component included in this proposal now reflects all accessibility enhancements and has been independently certified as WCAG 2.1 AA conforming via LevelAccess.

[tannerbachelor]

Our demo environment featuring the tab component in this proposal now reflects all accessibility enhancements and has been independently certified as WCAG 2.1 AA conforming via LevelAccess.

[bonnieAcameron]

Thank you so much for letting us know @tannerbachelor ! We'll have updates for you from our team soon.

[tannerbachelor]

Hi Bonnie, hope all is well. Is there any update from the team on the status of this request?

[bonnieAcameron]

Hi @tannerbachelor! Yes, I'm happy to say we have an update.

Thank you so much for your patience. As you know, we're a small crew and we found that we didn't yet have a process by which to fairly and transparently evaluate a contribution like this. We've worked internally to develop such a process, and would like to begin collaborating more closely with you soon. A teammate of mine will be reaching out within the next couple of weeks with further information.

In the meantime, this Thursday 8/17 we are discussing our roadmap, vision, and to some extent our evaluation process for the coming fiscal year in the USWDS Monthly Call. Please join us if you are able, and we'll reach out again soon.

[tannerbachelor]

Thank you! We're looking forward to it.

[smcharg-ohss]

I'm at the Office of Homeland Security Statistics and we're going to be moving a lot of our pdf report content into webpages (to comply with OMB M-23-22 and OMB M-24-08). All of the site hierarchy (primary and left nav) is used to get to the reports, so that leaves in-page navigation for navigating the reports. Tabs would allow an extra level of hierarchy to chunk the information in the reports in an understandable way.

Our current website: https://www.dhs.gov/ohss
Example of a report page (deep within the site hierarchy): https://www.dhs.gov/ohss/topics/immigration/yearbook/2022
Corresponding pdf (that we want to get into html): https://www.dhs.gov/sites/default/files/2023-11/2023_0818_plcy_yearbook_immigration_statistics_fy2022.pdf

In this example, it would be great to have a tab for the narrative at the beginning of the report, then a tab for each category (Lawful Permanent Residents, Refugees and Asylees, Naturalizations, Nonimmigrant Admissions, Enforcement Actions) that has an accordion for each table within the category. Without tabs, users would have to scroll through a list of 42 accordions. Given that most users are only interested in one category of data, tabs would allow users to get to their category much more quickly.

Here's an example from the Office of Natural Resources Revenue that took a pdf and turned it into an interactive page with a combination of tabs, cards, and accordions. Participants in usability testing found this and similar pages to be very easy to understand. https://onrr.gov/references/valuation/processed-gas-example?tabs=overview

A combination of tabs and accordions also works well for things like troubleshooting related to a particular topic. Example: https://onrr.gov/reporting/revenue?tabs=troubleshooting

Longer-term, we want to have more data visualizations on our site and tabs would also be a great way to toggle between different types of visualization or between visualization and corresponding documentation or downloads.
Example from EIA: https://www.eia.gov/petroleum/
Example from Office of Natural Resources Revenue: https://revenuedata.doi.gov/query-data

We'd be willing to help build and test the tab component.

I also found a couple of federal agencies that have a component documented as part of their design systems.
CMS tab component: Tabs - CMS Design System
VA tab component: Tabs - VA.gov Design System

[dara-icf]

Here at ICF, we came up with a CSS way to change the accordion to work like tabs -- allowing us to still be compliant with USWDS while also having tabs -- which is a very necessary component it web design. We are surprised it's still not a core component. Anyway, the code snippet proposed above is so much cleaner than the accordion component. We would love to move in that direction. The only question we have is about responsive - by using the accordion-- we just revert to an accordion on smaller break points. Hopefully this purposed tab component would work the same way. Other than that concern, I would push to get this done asap.

We would be willing to assist in building and testing.

[ICF-Matt]

I second @dara-icf I'm sure we can assist you in building and testing @tannerbachelor.