Replace color copy button icon with visible text

[afercia]

Fixes #57157

What?

Replaces the Copy color icon button with a button with visible text

Why?

• For accessibility and usability, icon buttons should only be used when there's not enough spaces for visibel text. Acois icon buttons, always prefer visible text.
• Better consistency with other Copy buttons e.g. the one to copy the permalink in the post-publish panel and ohter Copy buttons in the blocks toolbar.
• The previous icon button was completely unlabeled.
• Solves a problem with the disappearing tooltip that was supposed to show the confirmation text 'Copied!' adter a successful copy operation.
• The confirmation feedback now relies on the button visible text that changes to 'Copied!' . Although that's not ideal for accessibility, it is consistent with the copy permalink button in the post-publish panel.
• Avoids to use the tooltip entirely, thus avoiding to dynamically set an aria-describedby attribute.

How?

Replaces the icon button with a button with visible text.

Testing Instructions

• Select a paragraph.
• Go to the settings panel > Color > Text
• Open the coloro picker and expand it to set a custom color.
• Observe the Copy button now shows visible text.
• Click the button.
• Observe the text changes to 'Copied!' .
• Paste the clipboard content into a text editor and observe the color code has been copied and pasted correctly

Testing Instructions for Keyboard

Screenshots or screencast

Before and after:

[afercia]

I'll add a changelog entry later.

[ciampo]

Reporting @jasmussen 's feedback:

Let's not change the button to a text-label button.

It is intentionally an icon button so as to manage its prominence. The primary flow here is one of changing colors, where copying the hex code is a tertiary action, after even pasting into the input, or selecting from the input and copying. The button exists there as a shortcut for an advanced flow, and thus needs a lower footprint.

Let's find an alternative solution. I believe that adding a label={ __( 'Copy' ) } prop to the <CopyButton /> should give the button an accessible name

[afercia]

Reporting @jasmussen 's feedback:

Let's find an alternative solution. I believe that adding a label={ __( 'Copy' ) } prop to the <CopyButton /> should give the button an accessible name

Thanks for reporting @jasmussen feedback. I disagree with that feedback,

Let's find an alternative solution.

I'm proposing a solution in this PR. The responsibility to provide an alternative solution is up to the person who says 'no' to this approach. Frankly, it's not ideal for collaboration amongst contributors to just say 'no' without providing an alternative solution. I don't think that's in line with the principles that we all embrace in the WordPress project.

I believe that adding a label={ __( 'Copy' ) } prop to the should give the button an accessible name

Yes of course it would. But it wouldn't fully solve the problem.

[alexstine]

I'm not sure I'd consider a button to copy a hex code to be an advanced flow. This could just as easily be a clear button. I think the visible text would be an improvement for sure.

[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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @Sanyam-jain30.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: Sanyam-jain30.

Co-authored-by: afercia <[email protected]>
Co-authored-by: ciampo <[email protected]>
Co-authored-by: richtabor <[email protected]>
Co-authored-by: alexstine <[email protected]>
Co-authored-by: joedolson <[email protected]>
Co-authored-by: SaxonF <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: priethor <[email protected]>

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

[joedolson]

Adding an accessible name is the bare minimum so that this button is acceptable; but it still leaves it as an obscured control that's hard to recognize, for no particular reason.

I can appreciate the desire to lower the priority of a control, but this is obscuring the function of the control, particularly since it's different from other patterns for copying in the admin.

This is the only button in this interface, so I don't see any reason it can't be obvious. I'd like to bias towards clear, rather than away from it. Copying a color may not be the intent of this interface, but I don't see why that means it should be made difficult.

[SaxonF]

It would be nice if we could form some consistency when it comes to a "copy to clipboard" action beyond just the colour input . There may be some cases where it needs to exist in a dense environment so would be worth at least exploring other icon and success treatments.

A fairly standard pattern is more closely mapping copy icon to the actual value being copied, either within the input for example or just outside. Right now I'd argue the copy button is too detached from the input. A couple examples:

copy-state.mp4

copy-tooltip.mp4

[afercia]

A fairly standard pattern is more closely mapping copy icon to the actual value being copied, either within the input for example or just outside. Right now I'd argue the copy button is too detached from the input.

Looking back into this issue: yes I'd totally agree this Copy button should be moved close to the value that is actually copied. Screenshot with a couple examples of Copy buttons in the current editor UI:

[afercia]

Regarding the 'copied' confirmation indication, I'd just note that currently some of these Copy button use a Snackbar notice, some use a 'Copied' text that replaces the button text. Which is one more inconsistency.

[afercia]

I rebased on top of latest trunk and moved the Copy button after the value that is being copied.

From a perspective of logically grouping related controls, it makes sense to have what is being copied first and the Copy button after. From a visual perspective, the Copy button is now more closely mapped to the actual value being copied. It is also more consistent with other Copy button implementations.

Before:

After:

One more thing I would like to improve is to make the 'Copied' confirmation message, but that's for a separate issue.
RIght now the 'Copied' message across the editor is inconsistent. Some are Snackbar notices, some just change the button txt on the fly from 'Copy' to 'Copied' which isn't great and potentially problematic with longer strings provided by translati9ons.

[richtabor]

A few notes on why I don't think this works as-is:

Icon vs. text

We've had this conversation a number of times now. Perhaps if the "Show button text labels" preference is active, the text-only "Copy" button could be applied.

We could debate the value of iconography (in this case alongside a tooltip) but as we already have this preference, if you prefer—or require—text-only interface elements, you could have it that way.

Don't move the copy button

From a perspective of logically grouping related controls, it makes sense to have what is being copied first and the Copy button after.

It's much clearer having the "what" you are copying (the RGB, Hex, HSL) label right next to the copy control. Cognitively, I'm copying the RGB value, not rgb(255, 255, 255). As soon as the button is abstracted further down the panel, it's less clear what "Copy" is for. Is it for the last alpha value in RGBA?

Another con for moving copy below is the now the copy button visually moves. One, it's not ideal UX to move controls. Second, if some of my colors are RGB while others are HEX values, the copy button would exist in either place, anytime I open the color panel. I have to stop and look for it. if I want to copy color, loosing the benefits of procedural memory.

CleanShot.2024-07-26.at.10.37.47.mp4

Snackbar/copied state

Some are Snackbar notices, some just change the button txt on the fly from 'Copy' to 'Copied' which isn't great and potentially problematic with longer strings provided by translati9ons.

Curious. Is it problematic i18n wise?

I'm fine with a snackbar—that would work much better than the tooltip indicating a confirmed copy, which is less than ideal. This would be a solid enhancement.

The editor uses "Copied $variable to clipboard" for copying styles for example.

[richtabor]

Regarding the 'copied' confirmation indication, I'd just note that currently some of these Copy button use a Snackbar notice, some use a 'Copied' text that replaces the button text. Which is one more inconsistency.

I'm down to try the snackbar here. Certainly better than the tooltip indicating confirmation.