WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 3 weeks ago

#46698 new defect (bug)

Twenty Nineteen: use better color names for the editor palette

Reported by: afercia Owned by:
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords: has-screenshots has-patch
Focuses: ui, accessibility Cc:

Description

Color names were introduced in Gutenberg in https://github.com/WordPress/gutenberg/pull/5273 to address accessibility concerns and provide better information to users about the colors. See https://github.com/WordPress/gutenberg/issues/2699

Previously, colors were identified by their hexadecimal value. That wasn't helpful. By providing a human-friendly name (as many desktop applications do) all users can immediately understand what the color is.

However, Twenty Nineteen uses a couple names that don't help so much: "Primary" and "Secondary" are terms for designers, and don't help users to understand what the color is:

http://cldup.com/SS4v60kICo.png

Also, screen reader users won't have a clue "Primary" is a blue and "Secondary" is a dark blue.

Bundled themes should showcase best practices and these color names should be changed to human-friendly names able to inform users about what the actual color is.

Attachments (1)

46698.patch (1.0 KB) - added by kjellr 3 weeks ago.

Download all attachments as: .zip

Change History (17)

#1 @kjellr
4 months ago

Thanks for the ticket, @afercia. Another important note to include here: The reason the terms "Primary" and "Secondary" are used instead of more descriptive names is that those two colors change dynamically based on colors chosen in the Customizer.

So for instance, if you were to adjust the site to use a green instead of the default blue, those colors become shades of green instead:

https://cldup.com/gZddPt9dNP-3000x3000.png

This doesn't mean we can't choose better names, but it does mean we need to allow for a bit of flexibility for when custom colors are chosen.

#2 @afercia
4 months ago

@kjellr thanks, yep I seemed to recall something like that. Still, these names are not that useful :)

#3 @afercia
4 months ago

it does mean we need to allow for a bit of flexibility for when custom colors are chosen.

I'd tend to think before implementing dynamic colors in Twenty Nineteen, this should have been discussed with the Gutenberg team to see how to address dynamic colors names in the Gutenberg UI. /Cc @aduth

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 months ago

#5 @afercia
4 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.3

Moving to 5.3 consideration as per today's accessibility bug-scrub.

#6 @aduth
4 months ago

Would it be an improvement to update the texts to more clearly indicate that the color aligns to the one chosen as the site's primary color ? Something like "Site primary color" ?

The name provided to Gutenberg is ultimately chosen by the theme. Unfortunately, the field in the customizer for Twentynineteen is a "hue" color control, so it's difficult to assign meaningful names to each of the thousands of possible values.

If the generic label is out of the question, options for improving this could include:

  • Constrain the possible values for "Primary color" to a set of named colors
  • Find a tool which could provide some reverse-lookup to approximate color name from a given hex value (example)
  • At least provide a name for the default value
Last edited 4 months ago by aduth (previous) (diff)

#7 follow-up: @afercia
3 months ago

Unfortunately, the field in the customizer for Twentynineteen is a "hue" color control

Yep, I know. Would it be possible to:

  • use a meaningful name at least for the default colors? E.g. "Blue", "Dark blue"
  • fallback to the color value (as Gutenberg does) for custom colors? Color code: %s
Version 0, edited 3 months ago by afercia (next)

#8 in reply to: ↑ 7 @aduth
3 months ago

  • use a meaningful name at least for the default colors? E.g. "Blue", "Dark blue"

It should be reasonably straight-forward to do. There's already some prior art in the code to manage the default value for the color property. It would be a matter of doing the same for the name property and coming up with some meaningful name of the default.

https://github.com/WordPress/wordpress-develop/blob/3eb83ad/src/wp-content/themes/twentynineteen/functions.php#L146-L153

  • fallback to the color value (as Gutenberg does) for custom colors? Color code: %s

Is this is referring to the color selector in the Customizer? I'm not too familiar with how it works, but there are a few opportunities to hook into a change in value to e.g. speak. The markup itself is a series of div elements, so I'm not sure what options exist for assigning the meaningful label there. It's also unclear if those changes would occur in the Customizer's color control, the "Color Picker" abstraction, or the underlying Iris project.

https://github.com/WordPress/wordpress-develop/blob/master/src/js/_enqueues/lib/color-picker.js
https://github.com/WordPress/wordpress-develop/blob/3eb83ad/src/js/_enqueues/wp/customize/controls.js#L4113-L4174
https://automattic.github.io/Iris/

Edit: also, maybe the documentation should be improved a bit, as it seems the goal of the color names is not so clear.

Agreed. I created an issue: https://github.com/WordPress/gutenberg/issues/14989

Not sure if you had any specific thoughts about what that should include, in case you want to comment there.

#9 follow-up: @afercia
3 months ago

Is this is referring to the color selector in the Customizer? I

No :) I meant Gutenberg already fallbacks to the hex value when the color has no name: https://github.com/WordPress/gutenberg/blob/3d6fe8e3d9816b0017b9e1d69ced4103f67e7059/packages/components/src/color-palette/index.js#L35-L52

So when a custom hue is set via the Customizer, it wouldn't be possible to get a name for the Primary and Secondary colors in Gutenberg. Would it be possible to fallback to the hex value in this case?

#10 in reply to: ↑ 9 @aduth
3 months ago

Replying to afercia:

So when a custom hue is set via the Customizer, it wouldn't be possible to get a name for the Primary and Secondary colors in Gutenberg. Would it be possible to fallback to the hex value in this case?

Unless I'm mistaken, that would be on the theme to not provide a name for the custom color, which would then trigger the behavior you describe in falling back to the hex value.

Or, do you mean: Still allow the custom color to be named "Primary" or "Secondary", but otherwise provide a hint to Gutenberg to assign the aria-label as announcing the color code instead of this name? I could imagine a separate property of the colors object entry, e.g. 'dynamic' => true (userSelected, etc).

#11 follow-up: @afercia
3 months ago

Well "Primary" and "Secondary" won't help in any case. They need to be renamed to something like "Blue" and "Dark blue" otherwise users won't have a clue what those colors are. Maybe it's a matter of terminology: I'd call these the default values of the custom colors.

that would be on the theme to not provide a name for the custom color, which would then trigger the behavior you describe in falling back to the hex value.

Looking at what Twenty Nineteen does, see
https://core.trac.wordpress.org/browser/trunk/src/wp-content/themes/twentynineteen/functions.php?rev=44382&marks=145-154#L141

I'm not sure how a theme can not provide a name for a custom color, given the default values need a name. Instead, when users set a custom value via the hue picker, we can't predict the color name. I'm wondering if there's a way to make custom values fallback to the hex code.

#12 in reply to: ↑ 11 @aduth
3 months ago

Replying to afercia:

Looking at what Twenty Nineteen does, see
https://core.trac.wordpress.org/browser/trunk/src/wp-content/themes/twentynineteen/functions.php?rev=44382&marks=145-154#L141

I'm not sure how a theme can not provide a name for a custom color, given the default values need a name. Instead, when users set a custom value via the hue picker, we can't predict the color name. I'm wondering if there's a way to make custom values fallback to the hex code.

Similar to the conditional assignment of the 'color' property, I could imagine assigning null as the 'name' when it's not the default.

'name' => in_array( array( false, 'default' ), get_theme_mod( 'primary_color' ) ) ? 'Blue' : null,

#13 @kjellr
3 weeks ago

Checking back in to make sure we have some actionable steps for this one: We could specify "Blue" and "Dark Blue" for the default color labels, but what's the best solution for when a custom color is active? I'm guessing setting the name to null isn't ideal, right?

#14 @afercia
3 weeks ago

@kjellr thanks for looking into this. Looking back at the above conversation, seems to me there's the need to check if setting null for custom colors triggers the Gutenberg fallback that produces a label like Color code: %s.

#15 @kjellr
3 weeks ago

  • Keywords has-patch added; needs-patch removed

Looking back at the above conversation, seems to me there's the need to check if setting null for custom colors triggers the Gutenberg fallback that produces a label like Color code: %s.

Thank you for the clarification! I just tried it out and using null does revert to the color code. 🎉 I've attached a patch.

Here are the labels when the default color is used:

https://cldup.com/MFXgHj76g5-3000x3000.png
https://cldup.com/IunpjuKbTu-3000x3000.png

... and when a custom color is chosen:

https://cldup.com/aWfXLqm4gI-3000x3000.png
https://cldup.com/HYiRmQu2Jl-3000x3000.png

@kjellr
3 weeks ago

#16 @afercia
3 weeks ago

Glad it worked :) Seems to me this is the best we can do when a custom color is used 👍

Note: See TracTickets for help on using tickets.