Replace color copy button icon with visible text #57168
Conversation
afercia
added
[Type] Bug
|
I'll add a changelog entry later. |
afercia
changed the title
There was a problem hiding this comment.
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
Thanks for reporting @jasmussen feedback. I disagree with that feedback,
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.
Yes of course it would. But it wouldn't fully solve the problem. |
|
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. |
|
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 Unlinked AccountsThe 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. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
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. |
|
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.mp4copy-tooltip.mp4 |
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:
|
|
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
force-pushed
the
fix/color-picker-copy-button
branch
from
e85a9e5 to
7ecb450
Compare
|
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. |
There was a problem hiding this comment.
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.
I'm down to try the snackbar here. Certainly better than the tooltip indicating confirmation. |
The Snackbar pattern has inherent, obvious, accessibility problems that have been discussed at lenght at the time of its introduction. Sadly, the accessibility feedback at that time was totally dismissed and the Snackbar was introeuced anyways. I would strongly recommend against introducing new Snackbars. Thanks. |
Without sharing details I cannot understand your objections. If the snackbar needs to be improved to make it more accessible, as industry standard Radix toast, let's do it. Skirting standardized UX patterns will not result in a more usable WordPress. |
|
@richtabor, since you asked for specifics about the accessibility issues with the snackbar, here are two tickets that detail those issues, one of which has been open since 2019. It looks like @joedolson and @jeffpaul may be revisiting that second ticket to address issues, but in its current implementation, the snackbar is not a good choice for user status notifications. Just because other web projects use it doesn't mean it's good or right. |
I expect all contributors in this project to know the history of the project and research previous discussions, issues, etc. Thanks. |
|
As I mentioned on the Toolspanel issue, I'd recommend way more caution before pointing developers to examples or external libraries that are far from implementing the best practices we aim to see in this project and calling the Radix library an industry standard. That said, as pointed out in numerous issues and PRs across the eight years of life of this project, icon-only buttons have inherent problems and are inherently less accessible than buttons with visible text. The usage of icon buttons should be limited to only the cases where the UI in use doesn't provide enough space to show visible text. For example: toolbars. The icon buttons themselves should use a very limited set of very recognizable icons. IN all other cases, buttons should use visible text to provide the highest possible level of accessibility. Any other usage is inherently less accessible. Ideally, buttons and other controls should combine the best of both worlds and use both an icon and visible text. The most accessible apps and web UIs I can think of do use icon + text wherever possible, for good reasons:
Unfortunately, proliferation of icon-only buttons has spread over the years and they are now used everywhere even when not strictly necessary. Still, it's not a best practice to make an UI usable for everyone and we should avoid it whenever possible. |
afercia
force-pushed
the
fix/color-picker-copy-button
branch
from
7ecb450 to
661cddd
Compare
|
Rebased, moved the button after the inputs and made it compact size. Considering:
I opted to move the button after the inputs and reduced its size to compact. Screenshots:
|
|
Flaky tests detected in 661cddd. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12431072416
|
I expect proper context to be added wherever necessary. |
|
I appreciate your input here, but this still does not come across as an elegantly-designed solution. And how does one understand that "Copy"—at the bottom of all the values in RGB or HSL—is relative to copying the values collectively, and not just the last one (the one it's nearest to)? We need to aim for a much higher UI/UX standard. There are color palettes that are accessible and are also well-designed for an optimal color selection experience. We should not settle for less, because we want to add text to an icon button.
|
|
Is the argument here really about a copy icon vs. text that says "Copy"? If so, text always wins. It's anybody's best guess what icons look like and at least Copy is clear to most people what the button is meant to do. There have been comments over the years about icons providing better translation since icons are apparently universal across languages but I've seen little evidence to support this point. I think where things go off the rails for me personally is the constant obsession to make things look a certain way when we could be building things that work well for everyone. @richtabor If you can recommend an accessible pattern that is used in a design library, I'm happy to test it across screen readers. We've got to find a balance between looks and accessibility and since I've been contributing to Gutenberg, seems like accessibility is always a backseat after thought. I guess because you know, we're not the masses or whatever. That's ableism and it's got to stop. I've heard from actual sighted people that the icons can be a bit unclear in Gutenberg. I echo what @afercia said above. Icons are meant to be used in situations where the space is so limited, text wouldn't fit or might look unnatural. In this situation, it sounds like you want a button that floats to the right of the field so you can see the visual association. If we're being honest with ourselves, the argument that moving a button underneath a field would make it less understandable for a sighted person is nonsense. There are things you will get off a page that I will never get in a million years just because you have sight and I do not. This simply levels the playing field a bit and allows screen reader users and sighted people to have a more equal experience. As well as low vision users which might be zooming their screen in tight. That was me before I lost the vision I had. Icons were not great and trying to hover my mouse to see an impossibly small tooltip was miserable UX. Fully understand there are areas of the editor where icons are here to stay and can't go away. Formatting bars are a good example because you have limited space and lots to put there. This is not one of those situations. It's also worth pointing out that as users age, they may not understand/comprehend icons quite as well. This change could even help audiences with cognitive disabilities. Have a nice weekend, thanks. |
No, it's about the substandard layout and positioning of the copy button in the color palette. It's poorly designed as-propositions (essentially not designed)
Disagree. If a copy button is near a field, you assume it copies that field — not any combination of field values in the same popover. In it's previous placement there was less of a direct relationship between a single (or multiple) fields, and more of an association between the color value that would be copied (the Hex, RGB, HSL label). In it's current proposed form, we loose that association, having it now connected to the last field in the list of value—whichever it is.
Agreed. Although leveling the playing field should not infer shipping non-standard/sub-standard work that degrade the experience (sighted or non). We should always move forward.
Thanks, you too. :) |
|
@richtabor I don't think anything here will move forward if the button must be this tightly visually communicated. To me, you should be able to get away with a layout like this.
Are you saying that now it is impossible to know if the copy button will copy from the first input or the second input? If that's the case, copy could more reasonably be called in this example Copy Field 1. The text string is longer but now there isn't going to be an issue with a floating button on the right as the screen enlarges. You will still be able to tell based off the text which field value you are copying. Did I get this right? |
|
Screenshot of the Copy button where the text is now: 'Copy color'.
Problem solved 😆 |
No, not really. It's not the copy, as I mentioned before. It's the location. |
That would work if we're trying to copy each input value independently, but we're not. We're copying a composed value, formatted and all, based on the color formatting selected. For Hex it's just one field, but for HSL and RGB it's many.
I'd like to have examples of this component in other applications that have already solved this. This UI/UX is not new; we should use an established convention, rather than create something new. |
|
Looks like we are stuck here with thinking of not innovate a way to solve accessibility issue because everyone else is using same ui/ux with accessibility issue. I am personally in favor of having copy button as a text but if putting it after last field create confusions on what's it's copying, we can just put all fields in fieldset with border around and put copy button outside of that box, so everyone who can see understand that it's not just one field, it's copying all fields if that makes sense. I am not ui/ux developer or designer but I think some one from the project will understand above and create design for the same. It's not a rocket science. The issue here is, are we willing to solve it or not? If that problem solved, it's not that bigger issue to solve in terms of design and development like many other accessibility issue in the project. |
That’s what I am asking for. Instead of placing buttons arbitrarily, that we revisit this with a holistic solution that is a level-up from what we have today. Just because it may be nice to have a text label vs. an icon shouldn’t mean it’s ok to have a more confusing component. That’s counter-productive, much like this discussion has shifted towards, and what I am attempting to prevent. |
|
I don't really understand why having the Copy button at the end of the content is more confusing than having it in the middle of the content. This container has only one value in it: a color. I think it should be clearly understood that you're copying the color value, regardless of whether it's one or multiple fields. But this is not an arbitrary placement of a button: it is an intentional placement of the button, specifically appearing after the values it will be copying, rather than before. It's a placement intended to improve comprehension, particularly for users of assistive technology, and to improve consistency with other implementations throughout core. How would we feel if, instead of having the text 'Copy color', the button contained the word 'Copy' and a color disc representing the color being copied? That is a bit more designed; should make it visually clear what is being copied; but still leaves the button in the desired location with text. |
Yes, accessibility is a crucial component of user experience—but so is design. Design establishes expectations by aligning with established standards. When we deviate from those expectations, our software becomes increasingly difficult to use—for everyone. Accessibility and design aren’t at odds; they work together to create a cohesive, intuitive experience. In the same stride, I’m against pushing sub-standard experiences forward in the spirit of accessibility—just the same as I am against pushing sub-standard accessibility experiences forward in the spirit of making UI “pretty”. The notion that I, or other seasoned designers on this project, do otherwise is misguided. There is not a double standard, but rather a high standard. Let’s raise the bar and build experiences we can both be proud of, and more importantly, can use. |
A list of fields with a copy button below is not a clear, understandable, experience for copying a composed color value composed of multiple single values. In its previous placement, the copy button was aligned with the color format value. As so, hierarchy wise, it’s clear you’re copying the whole lot, in that specified value. As proposed, that connection is lost (regardless of icon or text). Again, I propose we review other accessible-forward color palette components to identify a standard we can adopt, rather than introduce a non-standard. |
Has this been validated? |
|
So I am in favor of putting it after all values. My logic for it is, if I am only using keyboard, I can go through all values and make adjustments first and after I can go to copy button with single tab. Now if i put it before fields, I have to go through all fields first to adjust values and second time back tab to go back to copy button. That will be bad user experience. So I think someone from design team should chime in and design a solution where this points are taken care of. |
There's always multiple sides to consider. To simply copy an existing value, now you'll have to key through each field, to get to it. UX wise, the more common interaction is to copy an existing color, rather than edit, then copy, a color value. |
I don't have a strong opinion on whether or where to display copy button text, but if we do display visual text, please note that the lengths of the letters For example, in Japanese, Screenshot of the copy button in its initial state. The button width is 63px:
Screenshot of the copy button when pressed. The button width is 128px:
|
Fixes #57157
What?
Replaces the Copy color icon button with a button with visible text
Why?
How?
Replaces the icon button with a button with visible text.
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
Before and after: