Button Block: No color contrast warning, regardless of chosen colors by shrivastavanolo · Pull Request #71272 · WordPress/gutenberg

shrivastavanolo · 2025-08-20T11:25:05Z

What?

The contrast warning is not appearing for Button blocks in WordPress Gutenberg, despite choosing colors with insufficient contrast, due to the color data being retrieved from the wrong node.

Why?

The issue needs to be fixed because the contrast warning is not appearing for Button blocks, even when the text and background colors have low contrast, due to the color data being retrieved from the wrong HTML element (wp-block-button instead of wp-block-button__link). This means that users may unintentionally create buttons with inaccessible color combinations.

How?

The changes modify the getBlockElementColors function in contrast-checker.js to handle Button blocks specially.

When a Button block is detected, the code now uses the .wp-block-button__link element instead of the .wp-block-button element to determine the text and background colors. This is because the colors are actually applied to the child div .wp-block-button__link, not the container element .wp-block-button.

The changes include adding a conditional statement to check if the block element is a Button block, and if so, using the .wp-block-button__link element to get the text and background colors. This should fix the issue with the contrast warning not appearing for Button blocks.

Testing Instructions

Add a Buttons block
Select the Button
In the sidebar, edit the text & background colors
Check if the contrast warning now shows up or not

Screenshots or screencast

Before

before.mov

After

after.mov

github-actions · 2025-08-20T11:49:56Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: shrivastavanolo <shreya0shrivastava@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: ryelle <ryelle@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Mamaduka · 2025-08-20T12:26:32Z

packages/block-editor/src/hooks/contrast-checker.js

+	// Special handling for button blocks - use the button link element for colors
+	let targetElement = blockEl;
+	if ( blockEl.classList.contains( 'wp-block-button' ) ) {
+		const buttonLink = blockEl.querySelector( '.wp-block-button__link' );
+		if ( buttonLink ) {
+			targetElement = buttonLink;
+		}
+	}


The similar exceptional cases and hardcoded block classes don't scale. Why?

What happens if the block classes or markup changes?

What if other blocks also use a different target for applying colors? Do we try to hardcode all possible cases?

How I would handle a similar case: See how the block editor decides where to apply the colors. Check if there are already existing helpers we can reuse. Try to reuse existing methods and declarative settings for the contrast checker.

P.S. IIRC, special cases like this will use the selectors definition to target the correct elements.

Hey @Mamaduka Thanks for the review! I updated this based on your comment, now using the block’s selectors.root definition instead of hardcoding classes, with a generic fallback to blockEl. This way it scales if block markup changes or other blocks define different targets. Can you take a look and let me know if this approach works?

Mamaduka · 2025-09-02T05:57:19Z

packages/block-editor/src/hooks/contrast-checker.js

+	const rootSelector = blockType?.selectors?.root || null;
+	let targetElement = blockEl;
+
+	if ( rootSelector ) {
+		const [ , ...rest ] = rootSelector.split( ' ' );
+		if ( rest.length ) {
+			const innerSelector = rest.join( ' ' );
+			targetElement = blockEl.querySelector( innerSelector ) || blockEl;
+		}
+	}


Have you tried using the getBlockCSSSelector method here? I think that should be the preferred method for getting block selectors.

The following code assumes that the first part of a selector will always be the block element, followed by child element selectors. I wonder if that will always be true, since it's a bit unclear in the docs. https://developer.wordpress.org/block-editor/reference-guides/block-api/block-selectors/.

@aaronrobertshaw, do you have any suggestions on how to handle this case best?

Thanks for the ping 👍

Have you tried using the getBlockCSSSelector method here? I think that should be the preferred method for getting block selectors.

In terms of retrieving selectors using getBlockCSSSelector would be the best method as it will handle fallbacks when the block hasn't migrated to using the Block Selectors API (e.g. still uses __experimentalSelector). It would also allow for fallbacks when the color.background|text|link selectors having been defined.

do you have any suggestions on how to handle this case best?

I don't have much in the way of solutions to propose at this stage, I'd need time to dig deeper here and unfortunately, I won't have that bandwidth for a month or two at least.

There are a couple of critical issues with the current approach though that I can confirm or highlight which might then help shape possible solutions down the road.

The following code assumes that the first part of a selector will always be the block element, followed by child element selectors. I wonder if that will always be true, since it's a bit unclear in the docs.

This is is definitely a critical bug with the current approach. There is no requirement that the first segment of a selector is the block wrapper's class. This was deliberately the case so that the selectors defined by a block can have full freedom.

So at first glance, I see the following issues:

Root block class

No requirement for the block class to be first in the selector

CSS combinators

Current splitting approach fails to take into account CSS combinators resulting in malformed selectors

This approach will break existing blocks such as Table which uses .wp-block-table > table

Comma separated selectors

These selectors probably need handling as they tend to represent use cases where elements may or may not exist depending on block configuration or state

Color feature selectors

The current approach assumes all color styles target the root block wrapper

Color styles can be applied via selectors.color.background|text|link etc

Crafting a generic solution that works for all blocks will not be a trivial task. Perhaps an interim solution or compromise that covers more use cases can be achieved. Either way, this PR will need some further work before it can be considered for merging.

Thanks for the detailed feedback, @aaronrobertshaw!

shrivastavanolo marked this pull request as ready for review August 20, 2025 11:49

shrivastavanolo requested a review from tellthemachines as a code owner August 20, 2025 11:49

Mamaduka added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Block] Buttons Affects the Buttons Block [Type] Bug An existing feature does not function as intended labels Aug 20, 2025

Mamaduka reviewed Aug 20, 2025

View reviewed changes

shrivastavanolo force-pushed the fix/button-block-color-contrast-warning branch from 2c78e06 to b4bc812 Compare August 26, 2025 08:28

shrivastavanolo requested a review from Mamaduka August 26, 2025 09:02

Mamaduka reviewed Sep 2, 2025

View reviewed changes

shrivastavanolo added 2 commits September 3, 2025 14:47

fix: add color contrast warning for buttons

a0cae5d

refactor: use existing function

d71a32f

shrivastavanolo force-pushed the fix/button-block-color-contrast-warning branch from b4bc812 to d71a32f Compare September 3, 2025 09:38

Mamaduka mentioned this pull request Sep 29, 2025

ContrastChecker: Fix check for button block colors #71959

Merged

Mamaduka closed this in #71959 Feb 18, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Button Block: No color contrast warning, regardless of chosen colors#71272

Button Block: No color contrast warning, regardless of chosen colors#71272
shrivastavanolo wants to merge 2 commits intoWordPress:trunkfrom
shrivastavanolo:fix/button-block-color-contrast-warning

shrivastavanolo commented Aug 20, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Aug 20, 2025 •

edited

Loading

Uh oh!

Mamaduka Aug 20, 2025

Uh oh!

shrivastavanolo Aug 27, 2025

Uh oh!

Mamaduka Sep 2, 2025

Uh oh!

aaronrobertshaw Sep 8, 2025

Uh oh!

Mamaduka Sep 8, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

shrivastavanolo commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Screenshots or screencast

Before

After

Uh oh!

github-actions bot commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mamaduka Aug 20, 2025

Choose a reason for hiding this comment

Uh oh!

shrivastavanolo Aug 27, 2025

Choose a reason for hiding this comment

Uh oh!

Mamaduka Sep 2, 2025

Choose a reason for hiding this comment

Uh oh!

aaronrobertshaw Sep 8, 2025

Choose a reason for hiding this comment

Uh oh!

Mamaduka Sep 8, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

shrivastavanolo commented Aug 20, 2025 •

edited

Loading

github-actions bot commented Aug 20, 2025 •

edited

Loading