Experimental Design [New tabs design]

skylerschain commented 7 months ago

What

This an updated version of tabs which we have deployed on the Claim Status Tool. We worked on this new design originally because of an a11y issue with the previous tab design. This tab style is more accessible and fits better with the visual style of the latest VADS components.
Previous
New

Purpose

Tabs allow content-rich pages to be subdivided into more manageable sections, creating a simpler and more organized user experience.

Usage

Tabs can be used for pages or products that are especially robust in terms of feature set or content volume.

Behavior

Clicking or tapping a tab takes the user to a dedicated page. Each tab is a separate react-router Link. Navigating between tabs take the user to a distinct URL.

Examples

Accessibility

This redesign was meant to resolve an existing 508 defect with the previous version of tabs. The new design was a collaboration between @skylerschain @jerekshoe and a11y experts Josh Kim and @davidakennedy.

NOTE: There was feedback earlier about how dark the gray line in the tab component is. We've updated it to a darker shade of gray and are now using $color-vads-color-base-lighter (#dfe1e2).

Guidance

Tabs are not necessary for most pages. First try keeping content on a single page with headers, but if you have simply too much content and clearly different types of content, then tabs are a great option.
Specs:
Tabs in our spec (mobile and desktop)
Hover state behavior for tabs

Research (optional)

These tabs tested well in our Evidence Submission usability testing earlier this year. Research Findings Prototype

Code (optional)

Include any existing code.

<nav aria-label="Claim">
<ul className="tabs">
<li>
<IndexLink
aria-current="true"
activeClassName="tab--current"
className="tab"
to={`your-claims/${id}/status`}

<span>Status</span>
</IndexLink>
</li>
<li>
<IndexLink
aria-current="false"
activeClassName="tab--current"
className="tab"
to={`your-claims/${id}/files`}

<span>Files</span>
</IndexLink>
</li>
<li>
<IndexLink
aria-current="false
activeClassName="tab--current"
className="tab"
to={`your-claims/${id}/details`}

<span>Details</span>
</IndexLink>
</li>
</ul>
<nav>

Next steps

You may present your work to the Design System Council at an upcoming meeting. If you do not or cannot attend the Design Council Meeting, you can opt to get an asynchronous approval.

Submit requests to join an upcoming Design System Council meeting in #platform-design-system.

During the meeting, the Design System Council Working Group will evaluate the request and make a decision.

If your request is approved, you can add your component or pattern to the system. If you have any questions on how to add your component or pattern to the system, please reach out to the Design System Team at #platform-design-system.

caw310 commented 6 months ago

@skylerschain can you attend the DSC meeting on Friday, Jan 5 to talk about this?

skylerschain commented 6 months ago

@caw310 What time are those again?

caw310 commented 6 months ago

@skylerschain the DSC meeting is at 1pm ET on Friday. I will add you to the invite.

skylerschain commented 6 months ago

@caw310 Are there specific questions I can prepare to answer, or is it more of a general conversation?

caw310 commented 6 months ago

@skylerschain , there isn't anything specific. Usually, it is just the request presenting the problem and how this design solves that problem and how it would be useful for other teams.

humancompanion-usds commented 6 months ago

In DSC on 1/5/24 we agreed that if Skyler and DK came up with some parameters around the behavior of the links within the tabs at 400% zoom then I could switch our existing guidance to point to this new version. The parameters are:

How long (in CSS ex would be ideal but px are find too) the tab name can be
The minimum and maximum number of tabs (leaning towards minimum of 3 and max of however many will fit at 400% zoom)
Directions on how the tab name should relate or be connected to the header for the tab (i.e. the current tab section header at the top of the content for that tab) for a11y

We also discussed that there are the following now in existence on va.gov:

In-page navigation

Tabs
On this page

Behavior - Navigation

Same page, refreshed data/content (Appointments future state using parameters)
Distinct URL and page, but displayed within the context of the original page (Claim status tool, existing Appointments)

Navigation

Link
Main Menu
Sidenav

Behavior - Navigation

New URL/page, page displays as different page (MHV secondary nav)

The Appointments tabs were requested already. We'll want to consolidate on one Tab design. I prefer the design in this request so leaning towards that.

humancompanion-usds commented 6 months ago

One thing I want to be clear on, normally the Design System Team would take on this work of taking the component, standardizing, making it bullet proof for uses in other contexts, etc. But given that we are in the midst of a large and all consuming upgrade to USWDS v3 we asked Skyler and DK to do some of this work for us. Once we're past this upgrade the DST will take on this type of work again.

humancompanion-usds commented 4 months ago

@davidakennedy - Any forward progress on this one? Just curious.

skylerschain commented 4 months ago

One update: I did recently tweak the component itself in Figma to make it more responsive to different tab labels.

We haven't figured out the answers to the questions posed above yet. But we're just getting through a major FE work phase so I think we can reprioritize this soon!

davidakennedy commented 2 weeks ago

@skylerschain and I have completed some more work on this. It's in a place where we think it's ready to have the design system team take a look, ask questions, and/or move the work forward.

Here's the design file with some of the specs.

And here some overall thoughts on the options we explored in the design file:

Overall accessibility for options

Of the three options, Option 1 is the best choice from an accessibility perspective.

Why: The menu has a simple design on mobile screens, and doesn't hide menu items behind a toggle. Past research with other similar menus on VA.gov performed well.

Other overall experience-related thoughts

How consistent are the icons used across the site for controls that are menus/expandable? For example, the main navigation uses the hamburger icon, but the logged-in menu uses the chevron.
A label for any collapsable menu will be a challenge, and should be standardized so a consistent approach gets implemented if a menu is used in multiple places on the site.
All of the mobile versions in each option require more research. Currently, the Benefits Management Tools team doesn't have a need for more than three menu items in the Claims Status Tool, and hasn't researched beyond that number of menu items.

Option 1: Stacked on Mobile

As mentioned, this option is the best from an accessibility perspective, and presents a good starting point for a new component.

Pros

Mobile design is simple, and doesn't hide menu items behind a toggle.
A similar menu performed well in testing on the Digital Health Modernization team when it tested a secondary navigation. Findings include: "Participants struggled, for a variety of reasons, with the collapsed navigation"
- Some participants did not seem to notice the menu
- Some participants did not come back to the menu after engaging with it
- A couple of the participants stated that persistent navigation/icon design (Prototype B) was “much improved” and “significantly easier.”

Cons

The use of truncation on smaller screens will be a challenge. It's generally difficult to make work for screen readers, and challenging for those with cognitive disabilities.
The component would take up more vertical space on mobile/small screens.

Option 2: Horizontal Scrolling on Mobile

This version isn't viable because the horizontal scrolling on mobile would violate Success Criterion 1.4.10.

Pros

Doesn't take up any more vertical space on small screens.

Cons

Violates Success Criterion 1.4.10.
On mobile screens, the scrollbar may not show up unless the container is touched first. This might mean Veterans may not know there are more menu items.

Option 3

This version shows as much of the menu as possible, and only hides a portion of items on smaller screens. It doesn't avoid hiding items though.

Pros

Still shows many of the menu items.

Cons

Hides some menu items, which haven't performed well in past research.

Let me know if you all have any questions on any of this.

department-of-veterans-affairs / vets-design-system-documentation