Block placeholder buttons have insufficient color contrast

[afercia]

Description

When adding a Group block, the block placeholder shows 4 buttons to choose a variation:

• Group
• Row
• Stack
• Grid

Visually, these four buttons contain only an icon. They don't have borders. As such, the icon must meet the color contrast ratio requirements for text.

The color of the icons is #cccccc against a white background color, which results in a contrast ratio of only 1.61:1.

Worth reminding there are two color contrast requirements:

• Text or images of text: at least 4.51:1. There are exceptions for large text. For normal icon buttons the editor by default uses #1e1e1e. The reasons is that icon buttons contain only an icon. As such, the icon acts as the 'text' amd must meet the requirement for text.
• Non-text Contrast: the visual presentation of ueer interface components must have a contrast ratio of at least 3:1. This applies to non-text, for example button borders.

In this specific case the icons are pretty big: 44 by 32 pixels. I'm undecided which contrast requirement these icons should meet and I'd appreciate some thoughts. Cc @joedolson

Anyways, the current ratio of 1.61:1 is too low.

Overall design

Looking at the broader picture, I'm not sure the design of the placeholder buttons is ideal in the first place. It's also inconsistent with other blocks. Screenshot to compare with the Columns block:

• The Columns buttons use a blue color for both the icons and borders. Historically, WordPress always used blue for intereactive controls.
• The Columns buttons do have borders.
• The Columns buttons are bigger, which helps targeting the button.
• More importantly, the The Columns buttons have some visually associated text. Unfortunately, the text doesn't match the accessible name, which is only revealed via a tooltip.
• Anyways, the visible text meets the contrast ratio requirement, as well as the blue used for the buttons.

Instead:

• The Group buttons use a too light gray.
• They aren't blue. As such they don't follow the pattern used by WordPress since ages.
• They don't have borders.
• They are smaller.
• They don't have visible text.

Overall, I'd like to propose to make the Group buttons (and other similar cases if any) look like the Columns one.

Step-by-step reproduction instructions

• Add a Group block.
• Add a Columns block.
• Observe the Group block placeholder buttons have an insufficient color contrast ratio.
• Observe the design inconsistencies between the Group and Columns buttons.

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

[afercia]

While working on this, I realized the Group block uses a custom placeholder that is inconsistent with all similar block placeholders that show variations, e.g. the Columns block.

The custom placeholder implementation for the Group block is basically a copy and paste, with a few adjustments, of the BlockVariationPicker block-editor component.

This is basically duplicated code for the only purpose to implement a custom design which I'm not sure adds a great value in the first place. The UI should be consistent.

From a code perspective, I'm not sure the editor should ever use custom, 'ad hoc' implementations.

The editor aims to use reusable components also in the user interface. Instead, 'ad hoc' implementations:

• In most of the cases they are duplicated code.
• They introduce maintenance cost in the long term.
• They introduce technical debt.
• They end up making the UI inconsistent in the long term.

Ad hoc implementations defeat the purpose of using reusable components in the first place, they don't meet the editor philosophy. They should be avoided at all costs.

If a design variation is desired for a good use case that is not an unique use case, then I'd say the best approach would be to introduce variants of the reusable component rather than duplicating code.

[joedolson]

Given that these are large, non-text controls, I think that meeting the 3:1 contrast specified in WCAG 1.4.11 would be sufficient. I don't see any reason these can't be darker; but 3:1 would be adequate.

I agree that the overall design would have more consistency if it matched the design used in columns. In particular, I like that the columns controls have visible text. I'm not sure what the best text for the groups controls would be, but something like "Normal", "Side by side", "Vertical stack", and "Grid" might be appropriate.

The minimum change necessary here would be to darken the control color to meet color contrast standards. But for the sake of design consistency and an improved interface, converting this to re-use existing patterns would be far better.

[afercia]

for the sake of design consistency and an improved interface, converting this to re-use existing patterns would be far better.

Thanks @joedolson. That's what I'm trying in #60217

[afercia]

Wirth noting in the Query Loop block placeholder the 'visual' labels do match the buttons aria-label attributes. This is a correct usage, as the visible labeling matches the accessible name. Screenshot:

[afercia]

Update: thc Columns block placeholder mentioned here for comparison has recently changed and went the with using the same insufficient color contrast icons of the Group block. That's a regression from #59275

Also, I would argue the same icon used for the 'Group row' and for the 'Two columns equal split' is really confusing. Screenshot:

Edit: I'd like to add thet, historically, interactive controls in WordPress are blue. The color gray doesn't really contey an element is interactive.

[joedolson]

I would argue that the columns block might not fail color contrast because the control is not dependent on the color of the icon; it has supporting text that meets color contrast. This is weakened, however, since you can't click on the text as a trigger; so if you can't see the icons at all, then it may be difficult to locate the click target.

I think we should open a new ticket to mark the regression from #59275, however. Unifying placeholders is great, but not if it moves in a less accessible direction.

[afercia]

Updated this issue title, as the issue now relates also to the Columns block and possibly other blocks.

[afercia]

Contrast has been improved in #62416.
There's still other pending issues to address though.

[afercia]

This is weakened, however, since you can't click on the text as a trigger

Yes because the visible text is not part of the button. In #62373 / #62412 I'm proposing to extend the Button component iconPosition prop to support also a top value. That would allow to implement the current design avoiding to use text that is just a 'visual label',

I'd appreciate some feedback on #62373 as I think the base component should be ore flexible but I'm getting some objections.

[afercia]

I'm going to close this issue as the color contrast has been fixed in #62416
Still, the Group placeholder is inconsistent with other placeholders, not sure why, and the labeling of the variations picker needs to be fixed. I will create a new issue.