Twenty Nineteen: use better color names for the editor palette

[afercia]

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:

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.

[kjellr]

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:

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.

[afercia]

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

[afercia]

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

[afercia]

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

[aduth]

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

[afercia]

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

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

[aduth]

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

[afercia]

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?

[aduth]

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

[afercia]

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.

[aduth]

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,

[kjellr]

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?

[afercia]

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

[kjellr]

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:

... and when a custom color is chosen:

[afercia]

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

[kjellr]

Adding a little extra note here, as I got temporarily confused myself:

46698.patch​ checks for the primary_color theme mod for both the primary and secondary colors. This is correct, since there is no secondary_color theme mod. The secondary color is set automatically based from the primary color, and it does not have its own theme mod entry. 👍

[audrasjb]

tested on a live website: the patch looks great!

[afercia]

In 45964:

Bundled Theme: Twenty Nineteen: Use human-friendly color names.

For better accessibility, the Primary and Secondary theme colors have now more understandable names.
Changes the names "Primary" and "Secondary" to "Blue" and "Dark Blue". Fallbacks to the hex color codes when the theme is set to use a custom Primary color.

Props kjellr, aduth, audrasjb.
Fixes #46698.