Inserter: Patterns and Media selected items insufficient color contrast ratio

[afercia]

Description

When selecting a Pattern or a Media category in the inserter, the category item is in a 'selected' state and an additional panel opens.

Semantically, the categories are a list with list items. The currently selected item does have a aria-current="true" attribute. So far so good.

However, visually, the selected state is only communicated by the means of:

• A subtle almost unnoticeable background color change.
• A subtle text color change.

As such, it is very hard to visually distinguish the currently selected category. As this is an user interface control, the different state should be communicated with a color change that has at least a 3:1 contrast with the adjacent colors. Alternatively, a shape with 3:1 contrast could work.

Screenshot of Patterns catgories:

The Patterns selected category name is repeated in the additional panel. That helps, but still the selected category can't be visually distinguished in the categories list.

Screenshot of Media categories:

The Media category name is not repeated in the additional panel

Step-by-step reproduction instructions

• Edit a post (or go to the Site editor)
• Open the inserter
• Click the Patterns tab or the Media tab
• Select one of the categories
• Observe the selected category is visually indicated only by the means of a slight colors change

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[joedolson]

This is very similar to #51582; we should probably use that pattern consistently.

[joedolson]

This would be a good example of something that belongs in design system documentation; we should be able to easily standardize these types of design decisions. See #53615

[afercia]

This is still an issue on current trunk and still needs a new design.
I agree it must be a design principle and it applies to other UIs as well, for example the navigation panel in the Site editor.

@WordPress/gutenberg-design I'd appreciate a new design to take into account what is reported in this issue. The selected indication must use a shape.

For reference, history, and inspiration, a similar problem was fixed for the WP admin menu hover and focus states in https://core.trac.wordpress.org/changeset/49961 / https://core.trac.wordpress.org/ticket/28599 by using a shape. The Customizer uses a shape as ell (only on hover). A similar shape could be used for the active state.

[jasmussen]

The screenshot in this issue is out of date. The active state has a chevron, the inactive does not:

What nuance am I missing?

[afercia]

The screenshot in this issue is out of date. The active state has a chevron, the inactive does not:

Right, the screenshot is out of date. The current chevron is a wrong pattern though. In #66448 we're discussing that all navigation items that open sub-panels should always show a chevron to indicate the presence of a navigation mechanis,

The chevron should always be visible for all the items. As such, it can't be used for the selected state.

[jameskoster]

This will apply to all instances of the Tabs component (in vertical orientation). Perhaps it would be better to open a new issue to focus on that?

[afercia]

This will apply to all instances of the Tabs component (in vertical orientation). Perhaps it would be better to open a new issue to focus on that?

Either a new issue or maybe broaden the scope of #66448. I'm not sure it matters whether it's a Tabs component or another component. From an user perspective, clicking on these 'things' open a sub-panel. I think all such 'navigational' items should use the same design and probably it's best to establish a general design principle in the context of #66448.

[jameskoster]

@afercia During the recent refactor, it was agreed that displaying a chevron on the active tab in the vertical orientation is an acceptable shape change for distinguishing between active and inactive tabs. This approach is consistent with the horizontal orientation, where a shape appears beneath the selected tab. If that's not the case then I think it would be good to document the requirements in a dedicated issue.

You may argue that a chevron isn't an appropriate shape for tabs if we aim to establish a heuristic where chevrons indicate drilldown behavior specifically. I wouldn't disagree with that.

[afercia]

@jameskoster the implementation of the vertical tabs for patterns/media is very particular and sort of stretching the concept of the ARIA tabs interface.

As discussed in other issues/PRs, this specific implementation doesn't show an initial tabpanel open by default.

I would argue that the lack of an initially open tabpanel breaks the ARIA pattern and also makes this design pattern not a 'real' tabs UI. Regardless of the component used for this UI, from a visual perspective and more importantly from an user experience perspective, these don't really look like tabs.

As an user, what I see here is a series of items. When I click on one of them, a sub-panel opens. It's not a drill-down menu but it opens a sub-panel (actually a tabpanel) anyways. Visually it's like a menu that opens sub-panels. My point is that the chevrons should always be visible to indicate the items open a sub-panel. There's really no big conceptual difference between this particular vertical tabs implementation and a drill-down.

As such, I think the usage of the chevrons should be consistent across the whole editor and should always indicate navigation to or opening of a sub-panel, whatever the actual component in use is. Instead, using the chevrons for the hover/focus/selected state introduces a clear inconsistency. Not to mention the Navigation panel (the black one) in the Site editor uses chevrons to indicate navigation as well.

GIFs to illustrate.

Vertical tabs	Drill-down

[jameskoster]

Sorry, it's still not 100% clear to me whether this issue is local to the pattern inserter due to the unconventional use of the tabpanel pattern, or also an issue in the Tabs component itself. I'd like to avoid an ad hoc fix for this one scenario if fixing the component can solve the problem across all vertical tab instances. The tabpanel behavior in this context feels like a separate thing.

Btw it could be worth keeping an eye on this PR. The changes there suggest making the first panel open by default, thereby respecting the tabpanel pattern.

[afercia]

it's still not 100% clear to me whether this issue is local to the pattern inserter due to the unconventional use of the tabpanel pattern, or also an issue in the Tabs component itself.

I would say both :)