New color picker improvements, second round

[afercia]

Follow up to #2679

See also Slack discussion https://wordpress.slack.com/archives/C02QB2JS7/p1504633514000516

I'd like to propose to consider a few further improvements for the color picker:

• add some indication about the currently selected color before the set of buttons: "visually it’s clear, but if you are on a screen reader you may have to go through a number of items before you get to the one selected."
• ideally, colors should have a human-understandable named color. While the required format is hex or rgb or maybe other that will be added, I guess many users (not just a11y users) would just like to pick up a color. Other applications already refer to colors with a name:

also for color variations:

this could be implemented requiring to specify a color name in gutenberg_color_palette().

[gschoppe]

This change would be useful to agencies, to provide branding hints... e.g. "Primary Brand Color" "Secondary Brand Color", "Green Accent", etc

[afercia]

Yep, not to mention accessibility because a string like, for example, #8ed1fc gets read out as:
number eight ed one f c which is not so useful for assistive technology users.

[gschoppe]

Sorry, yes, I meant that as "in addition to a11y concerns, it would assist agencies"

[afercia]

Sure 🙂 And your point makes perfectly sense. I haven't thought at that and seems to me one more good reason to consider named colors.

[gschoppe]

Just a side note, thank you for the incredible a11y work you've been doing for the team. I work for an agency that often contracts out with an accessibility-oriented firm, and the level of thought that you put into your work is very heartening to see. I'm well versed in how little fun it is to boot up a screen reader and test interfaces over and over again that were designed by sighted developers for mouse-driven interactions.

[afercia]

@gschoppe thanks. I share that feeling on a daily basis... 😬

[00travelgirl00]

@afercia okay, now I understand your point with the labels for colors.

How it would work with the open color picker? Or do we only define labels for specific colors?

also how @gschoppe mentioned it would be nice to define own colors with labels.

[gschoppe]

The label could expand, tool-tip-like on focus/hover (although that often leaves touch users in the cold). and, of course, it needn't be visible for screen readers. However, human-readable, visible color labels would also assist sighted users with any form of color impairment.

[afercia]

Gutenberg tooltips work in a way that they use the same text used for the aria-label attribute, so that would work for sighted users and screen reader users. Worth also considering not all screen reader users are completely blind; many users with low vision use screen readers as an aid.

[gschoppe]

how do gutenberg tooltips perform on touch devices, like phones?

[afercia]

@gschoppe I think that's untested and still to address.

[afercia]

Re: better identifying colors, apart from giving them a human-understandable named color, here's some feedback from users about giving them also a tooltip, which makes sense to me, see https://make.wordpress.org/accessibility/2017/11/28/screen-reader-user-experience-with-gutenberg/

the user can select colours for text and background. It would be useful to have the name visible on hover. This will be useful for colourblind people.

[afercia]

Reported by one of the accessibility testers:

• What the user hears is the hexadecimal code of the color. It will be better if the name of the color was used instead of the code hex.

[jorgefilipecosta]

Hi all, thank you for the discussion that happened here. The improvements to the color related components were merged. I think we can now close this issue if there is any other improvement needed to feel free to reopen.

[afercia]

Thanks everyone for the discussion, feedback, and thanks @jorgefilipecosta very good job!