Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#46698 closed defect (bug) (fixed)

Twenty Nineteen: use better color names for the editor palette

Reported by: afercia's profile afercia Owned by: kjellr's profile kjellr
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 (2)

46698.patch (1.0 KB) - added by kjellr 5 years ago.
Capture d’écran 2019-09-03 à 18.06.13.png (32.8 KB) - added by audrasjb 5 years ago.
tested on a live website: the patch looks great!

Download all attachments as: .zip

Change History (26)

#1 @kjellr
5 years 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
5 years ago

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

#3 @afercia
5 years 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.


5 years ago

#5 @afercia
5 years 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
5 years 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 5 years ago by aduth (previous) (diff)

#7 follow-up: @afercia
5 years 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

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

Last edited 5 years ago by afercia (previous) (diff)

#8 in reply to: ↑ 7 @aduth
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years ago

#16 @afercia
5 years ago

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

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


5 years ago

#18 @kjellr
5 years ago

  • Owner set to kjellr
  • Status changed from new to assigned

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


5 years ago

#20 @kjellr
5 years ago

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
5 years ago

tested on a live website: the patch looks great!

#21 @audrasjb
5 years ago

  • Keywords commit added

#22 @afercia
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#23 @afercia
5 years ago

  • Keywords commit removed

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


5 years ago

Note: See TracTickets for help on using tickets.