Command Palette: highlighted suggestions insufficient contrast

[afercia]

Description

In the Command centre, users can 'highlight' suggestions by using the Down and Up arrow keys, or by hovering on them.

Worth noting this is not a real 'focus' style. Actually, focus is on the search input. The suggestions are highlighted and 'selected' via scripting. Nevertheless, since it is possible to select and activate the suggestions, users need to have a clear indication of what the highlighted / selected suggestion is.

The highlighted state style only relies on a subtle color change. Color only is not sufficient. Teh highlighted style needs a shape, whether it's an outline or a left border like in the classic admin menu.

Aside: I think this 'highlighted' style is used also elsewhere. It should be fixed wherever it is used.

Screenshot: hint: the fourth suggestion is the highlighted one.

Step-by-step reproduction instructions

• Go to teh Site editor.
• Open the Command centre.
• Enter a search term e.g.: 'template'.
• Wait for the list of suggestions to be displayed.
• Use the Down and Up arrow keys to navigate the suggestions.
• Also try hovering the suggestions.
• Observe the highlighted style only uses a color 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

[jameskoster]

Previous mockups for suggestions have included a classifying label, e.g. "Command", "Shortcut", etc:

If such as label was iconised and exposed on hover, would that qualify as a shape change?

[jasmussen]

I suggested a "Run command" text a la GitHub on the PR, but I like the arrow better. I wonder if it should be a chevron? It could also be a little [Run] chip design. But yes, it qualifies as a shape change.

[jameskoster]

At the moment we have the following 'types' of actions:

• Shortcut – E.g. go directly to the Styles panel
• Command – E.g. Delete a template, Add a page

It might get a little fuzzy if we have different icons for each? So I would be tempted to stick to a single icon to begin with, if we go down that route and revisit if/when more action types are added. I chose the Arrow instead of the Chevron since we use chevrons to indicate drilldowns elsewhere, but maybe that doesn't matter? Or maybe there's another icon to try.

Text labels would probably be clearer: [Run] for commands, [Jump to] (or similar) for shortcuts.

That would enable us to remove the 'Open...' prefixes too which are a little ambiguous imo. For that reason I'm starting to lean more towards the text labels 😅

[jasmussen]

Single icon sounds like a good start and is easy to implement, and doesn't preclude revisits in the future.

[jameskoster]

Yep, that's a good point. Alternatives to the arrow:

Return

Could be a hint for keyboard interaction?

Chevron

I worry this suggests a drilldown which isn't what happens. Not a stong feeling, but maybe we should reserve this in case drilldowns are added to the command palette down the road?

[jasmussen]

Good point on the chevron. I don't personally share the full concern, though I would think the regular arrow works better than the return.

[afercia]

While the arrow could work, I'd rather suggest to look at the big picture and try to standardize this 'highlighted option' style across the UI. As far as I can tell there are at least two components that show a list of options:

• Combobox (search + suggested options)
• CustomSelectControl

where the highlighted style is largely inconsistent. A few examples:

Slash inserter:

Link suggestions:

Tag suggestions:

Position settings:

Comment date format:

Font appearance:

[jameskoster]

Since (as pointed out in the OP) this isn't a true focus, wouldn't it be a little contradictory to use the outline treatment?

Perhaps it would help to better define 'shape change' for this context? IE why is adding a background color not a shape change? Isn't it the addition of a shape where none was previously visible? Would it be different if the background had stronger contrast, IE:

To be clear I'm not proposing we do that, just trying to better understand the problem. Thanks.

[richtabor]

I worry this suggests a drilldown which isn't what happens.

We may have drilldown commands one day too.

[afercia]

After two months this issue has been created this still needs a design decision. In the meantime, the command center has been realeased in WordPress 6.3. It's unfortunate that a such prominent feature gets released with an insufficient accessibility (and usability) level. Honestly, I'm not sure this way of releasing software is ideal for a project that aims to match a high quality level.

That said, this only needs a design decision. The implementation part is just CSS. The challenge here is mostly about making all the autocomplete comboboxes look the same across the editor. As of now, there's still large inconsistency across all the autocompleters and I'm no sure this is ideal for users and for the reputation of WordPress.

Couple screenshots from current trunk:

Command center: the highlighted suggestion is barely visible:

Tags: totally different styling and also functionality, as the search term is underlined within the suggestions:

[joedolson]

We shouldn't need to wait on a global design decision in order to fix an extremely obvious accessibility problem. We can resolve the accessibility problem with a very simple design change to improve contrast; all of the other larger design issues can be resolved after fixing the accessibility issue.

We need to keep in mind that fixing an accessibility issue has a direct and immediate impact on users who depend on it; it resolves a major user experience problem for the people it impacts. The other design issues need to be done with accessibility in mind, but should not block us from fixing an immediate problem.

[jeryj]

To close this issue, we only need a decision on the colors to use to highlight the suggestion. Those colors need to have sufficient contrast. The other design decisions on icons and consistency across the editor can be a follow-up.

[richtabor]

Since (as pointed out in the OP) this isn't a true focus, wouldn't it be a little contradictory to use the outline treatment?

This unanswered question is what's holding up.

We shouldn't need to wait on a global design decision in order to fix an extremely obvious accessibility problem.

We should always push for consistency, rather than ad-hoc fixes (which results in varying experience like expressed in this comment above  — but I do agree we need to resolve this.

That saying, here's what we have today:

And below are the options:

Request

The options above are based on other variants of existing flows within the editor.

Do you mind detailing what won't work (and why), as well as what will work (and why). That would help clear the air and move this forward (as well as consolidating the other suggestion + selection flows).

I would like to come to a solution that we can apply consistently everywhere, so in the future when something like this comes up there is a clear standard. cc @WordPress/gutenberg-design

[joedolson]

Any of the combinations that meet basic accessibility standards for color contrast will work. Beyond that, I have no concern about which design is used. Not knowing which colors are represented above, I can't say with certainty which of those meet standards.

[jeryj]

Since (as pointed out in the OP) this isn't a true focus, wouldn't it be a little contradictory to use the outline treatment?
This unanswered question is what's holding up.

I don't think there's a standard around this, and it's more about consistency and color contrast than which specific style is chosen. That said, since the outline focus is used on the inputs and sometimes wrapper depending on context, that having a solid color background to show selection will be the best choice. Whichever solid color background that meets the color contrast guidelines (4.5:1 for AA standard) sounds good to me.

The purple one is appealing, as it has strong contrast with both the text inside the color and against the white background. It also feels a bit more modern and bold to me. The light gray background makes it harder to see which one is selected since there's not much contrast between the light gray and white background.

[richtabor]

@joedolson I'm trying to work with you and move this forward. I personally have concern for accessibility and design—we do need both.

Not knowing which colors are represented above, I can't say with certainty which of those meet standards.

All options are placed on a #FFFFFF canvas:

Option one:

• Background #FFFFFF
• Foreground #3858E9 (based on current admin color scheme)

Option two:

• Background #3858E9 (based on current admin color scheme)
• Foreground #FFFFFF

Option three:

• Background #F0F0F0
• Foreground #1E1E1E

Option four:

• Background #E0E0E0
• Foreground #1E1E1E

Option five:

• Background #FFFFFF
• Foreground #3858E9 (based on current admin color scheme)
• Outline #3858E9 (based on current admin color scheme)

[jeryj]

Did some Googling to confirm. I could be wrong, but I believe that to meet AA guidelines the color combinations need to pass two checks:

• The color of the text on the selected item background needs to be 4.5:1 or higher
• The background color of the selected item and the background color of the command palette need to be 3:1 or higher.

Out of those options, only option 2 meets those guidelines. The others don't meet the 3:1 contrast guideline between the selection background and command palette background.

[joedolson]

@richtabor I don't have any personal preference about the design choices. I favor the inverted contrast (2) and the outline option (5), because they offer a higher degree of visual affordance of the selection. I apologize for being curt in my previous response.

@jeryj's description is accurate, as far as contrast is concerned. When color is the only distinguishing factor, both contrast requirements need to be met: the first describes the ability to see the text against it's background (readability) and the second describes the ability to distinguish which item is selected.

However, because there's an icon present that also indicates which item is selected, the second color distinction isn't necessary - that color contrast distinction is only required if color is the only differentiation between selected and unselected items. What Jerry is referring to is success criterion 1.4.11: Non-text contrast.

If the selection icon was also below contrast requirements, that would be a problem.

[jeryj]

Ah, so if there's an icon to demonstrate selection then we don't need a different background color to show selection. I think in this case though, the "Open in a new tab" icon isn't to show selection but the icon that is associated with that item. Here's an example of the command palette search results with more item types, each with their own icon. I'm guessing we wouldn't want to add another icon to the mix to show selection.

Would an outline to show selection meet AA guidelines here?

[richtabor]

I think in this case though, the "Open in a new tab" icon isn't to show selection but the icon that is associated with that item.

Correct. Icons are assigned when a command is registered.

I'm guessing we wouldn't want to add another icon to the mix to show selection.

Yea, I'd rather lean on color to indicate selection rather than more iconography.

[joedolson]

In that case, yes - only option 2 achieves the needed goal. Based on the examples, it seemed like the icon was being used to indicate which item was active, but if that's not the case, we'll need to make sure all the color contrast baselines are met.