ColorPalette: Disable Clear button if there's no color value.

[juanfra]

What?

Fixes #67107

Disable the "Clear" button if there's no color value for the color palette component.

EDIT: I also applied the same logic to the GradientPicker and DuotonePicker here.

Why?

The “Clear” button in the ColorPalette is currently active even when no color value is set. This can be confusing for users, as clicking the button doesn’t do anything in this case. It would be more intuitive if the button were disabled when there’s no color to clear.

How?

By setting it disabled. if there's no value.

Testing Instructions

Color picker & gradient picker

1. Create a page.
2. Add a paragraph.
3. Check the background color, that if there's no background color the "Clear" button is disabled.
4. Check that if there's a background color, the "Clear" button should be active and you could perform the action normally.
5. Repeat with the text color, and confirm the same results.
6. Repeat with the gradient picker.

Duotone

1. Create a page, using a theme that has duotone presets.
2. Add an image.
3. Try applying duotones, confirm the clear button is disabled if there's no value.

Screenshots or screencast

Screen.Recording.2024-11-19.at.10.56.44.mov

[github-actions]

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: juanfra <[email protected]>
Co-authored-by: ntsekouras <[email protected]>
Co-authored-by: afercia <[email protected]>
Co-authored-by: Mayank-Tripathi32 <[email protected]>

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

[ntsekouras]

Let's also add accessibleWhenDisabled prop here.

[juanfra]

Thanks for the review. I've added it. I also applied the same logic to the GradientPicker and DuotonePicker.

[afercia]

Let's also add accessibleWhenDisabled prop here.

Thanks for catching that.

[github-actions]

Flaky tests detected in 50d781e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11915640893
📝 Reported issues:

• [Flaky Test] submenu click on the arrow interactions #61884 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

[ntsekouras]

LGTM, thank you!

[afercia]

It's worth reminding why in most cases there is the need to use accessibleWhenDisabled when disabling a button.
Under the hood, it uses aria-disabled instead of the HTML attribute disabled.

When using the keyboard, disabling a button on the fly with disabled would make the button no longer focusable while focus is on it. As such, there would ba a focus loss. After tabbing again, the tab sequence would start from scratch from the document root (although browsers try to remediate in some way).

To avoid focus losses and to make controls discoverable also when disabled, Gutenberg uses the aria-disabled pattern + some styling.

[juanfra]

Thank you both!

And thanks, @afercia, for the detailed explanation—I’ll definitely keep that in mind moving forward. 🙌

Merging this one now! 🚀