Content switcher carries the same visual weight as the primary button.

[noah-kawashbarnes]

The content switcher’s visual weight equals that of the primary button, dividing the user’s attention and preventing them from easily identifying the primary action on the page.

Detailed Description

The current design uses high contrast to help the user distinguish which of the content switcher options are selected, but in many cases this contrast makes the content switcher appear too prominently on the page, or it directly conflicts with the primary button component. Overcoming this issue is difficult as concept itself relies on contrast to make the selected option obvious to the user. To add to this difficulty, accessibility concerns have also been raised in regard to the contrast between the content switcher’s unselected items, and the theme backgrounds.

A proposed solution is to provide a second content switcher option, which would have a lower visual weight than the original design, but still retains enough contrast to meet WCAG requirements and provide the user with an easily identifiable ‘selected’ state.

All of the following designs have been tested against the accessibility concerns raised here and are compliant with WCAG contrast regulations. These designs have also been tested to ensure they are as usable as the current design, and that users are able to easily identify which item is selected, even when using the 2-option variant.

White Theme

Grey 10 Theme

Grey 90 Theme

Grey 100 Theme

[dakahn]

@carbon-design-system/design proposal to lower the contrast of the content switchers selected...switch so it doesn't have the same visual weight as a call to action button (for example)

We can track any accessibility issues with the Content Switcher Component in #6745 and we can discuss visual weight concerns in this issue.

[aagonzales]

Some ideas from Mitchell. They have not been vetted for contrast accessibility just posting for posterity.

[aagonzales]

I'm actually liking this direction, especially in context (see comment above).

[aagonzales]

Other ideas I had

[noah-kawashbarnes]

@aagonzales With a small tweak to the borders that approach should comply with contrast accessibility rules. I went ahead and mocked it up with the necessary borders and threw in a few alternatives here: https://ibm.invisionapp.com/share/MHO16NYFBPK#/screens/319971991?browse

[joshblack]

Great article in this space https://medium.com/tap-to-dismiss/a-better-segmented-control-9e662de2ef57 👀

[noah-kawashbarnes]

Link to the updated designs and completed sketch symbols: https://ibm.box.com/s/0tfwkywn8a4ym8zv2vt82d9qitagx2oq

[kingtraceyj]

PLG teams using subtle content switcher:

NS1:

Instana:

[mjabbink]

@aagonzales I like what you and Mitchell have sketched out.

[Jonathan-Bruckbauer]

Hey, as @aagonzales raised attention to this after yesterday's DSAG meeting, I gave it a stab and created some variants based on the previous work done by Mitchell, @noah-kawashbarnes and @aagonzales.

Figma file: https://www.figma.com/design/FEKeP8Lv9ZH6gJoh7anJoN

Click + zoom for full res:

Version 1—4 use a lighter background for the selected option and a darker background for the unselected options.
Version 5 is the other way around just as the high contrast content switcher works. Darker background for the selected option, lighter for the unselected options.

I'd suggest to go with V5 if we would have two varying stylings of the content switcher (high contrast / low contrast).
If the content switcher's current styling would be replaced by the low contrast styling, then I'd go with one of Version 1 to 4. If I had to choose between V1 to 4, I think I'd pick V3.

[mjabbink]

I don’t think there is an issue. It’s easy to make it one but is it really?

From the exploration in Figma, I think V2 works the clearest except in the Disabled state. The selected type is lighter than the deselected type. I think this needs to be reversed so the selected type is slightly darker than the deselected type colors. It should be as though the entire disabled state is just a faded version of the enabled.

[mjabbink]

I think V2 distinguishes the Content Switcher from the button more as well, and although V5 is not necessarily a bad design, it has a higher level of similarity to the button.

[aagonzales]

@mjabbink @Jonathan-Bruckbauer I've got two points of feedback:

1. I'm concerned that the selected option of the low contrast version looks like the unselected version of the default switcher. Maybe as long as those switchers never appear on the same page (or product?) then it won't be a problem. But we may have to spell that out in the usage documentation.
2. I believe some element of the unselected content switch item needs to pass 3:1 contrast. Originally the default content switcher didn't that high contrast stroke around the unselected but we had to add it for accessibility. See the original issue Content switcher fails WCAG 1.4.11 Non-text Contrast #6745.

[aagonzales]

@mjabbink and I were exploring some things and we think something like this could work if it passes all the accessibility checks.

Or with rounded corner for selected

[dianasanborn]

A few updates on this work —

8/14 Carbon Office Hours:

I presented this topic to the group and we discussed all of the explorations above.

Key takeaways:

• The group leaned towards having the corner radius on all sides of the selected item because it made the selected item feel like it sat on top of the other options more and visually worked better.
• We looked at the light and dark theme variants and were conflicted on opposing styles that worked better for each.
• The two highlighted options were the leading contenders, and we wanted to put it in context with other UI components as a next step

8/20 Carbon Office Hours:

I presented our top choices back to the group in context with different screens and themes.
Figma file

Key takeaways:

• Everyone still thought our first choice options worked best for the different themes
• We prioritized usability and what visually worked better over the systematic token usage between themes
• For next steps we did a final review with Mike A. and Jeannie to get their thoughts

Final review

• Everyone still agreed on the top choices for the different themes
• Since the new component will have component-specific tokens, we decided to keep the same colors for both the White/Gray 10 themes and Gray 90/Gray 100 themes
• The same corner radius will also be updated to the high contrast content switcher
• Final decision and specs can be found here