search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.53k stars 4.21k forks source link

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

Closed juanfra closed 2 days ago

juanfra commented 3 days ago

What?

Fixes https://github.com/WordPress/gutenberg/issues/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

https://github.com/user-attachments/assets/235ff9ac-b561-4e60-ad8d-ddc25dedac52

github-actions[bot] commented 3 days ago

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 <juanfra@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>
Co-authored-by: Mayank-Tripathi32 <mayanktripathi32@git.wordpress.org>

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

github-actions[bot] commented 3 days ago

Flaky tests detected in 50d781e8aae86ade99e7c9b0b80c3ce7daf661ee. 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:

afercia commented 2 days ago

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 commented 2 days ago

Thank you both!

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

Merging this one now! 🚀