Block actions not highly visible

[anevins12]

Describe the bug
Some actions associated when adding a block are coloured lightly and are not highly visible and achieve a contrast ratio below 3:1 (against the white background). These actions are conveyed as icons, as seen in the screenshot below:

This is regarding WCAG 2.1 'Non-text Contrast': https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

To Reproduce
Steps to reproduce the behavior:

1. Edit a page;
2. Click on the new block description field "Add text or type / to add comment" so that this component receives focus;
3. See the block actions appear to the right. These are functional and not-disabled actions.

Expected behavior
Icons that are functional and not disabled should be highly visible. Practically we need to darken the grey colour of the icons. I suggest using the same colour as the add-block plus icon (something around #555d66).

Desktop (please complete the following information):

• OS: Ubuntu
• Browser: Chrome
• Version: Latest

[mtias]

This is meant to be a very secondary shortcut for convenience, I feel calling too much attention to it could actually distract people from other entry points. Adding "design feedback" label.

[karmatosed]

I would underline this is meant to be a guide. I think if possible keeping this as it is would be great. However just to try and find a balance, what is the color you would be suggesting of a grey to make it accessible in your eyes? Just so we know what we're talking about.

[anevins12]

@karmatosed See the PR #7208 - I have implemented my suggestion.

I would underline this is meant to be a guide

I'm not trying to police a guideline, I am pointing out the problems and suggesting solutions via pull requests.

It would be better to provide a solution that works for a wider audience, than one that works really well for some users and is not usable for others.

[karmatosed]

This isn't a guideline I am saying in this case the interface is simply a guide not a primary or secondary action needed to be seen at the surface level.

[hedgefield]

I'd say this is a function of the software, same as any other, and as such should be visible for anyone, whether it is non-essential or something we want people to use or not.

We use #646464 for gray text that passed WCAG.

[afercia]

These are buttons. They're UI controls and they need to be perceivable by everyone. Whether they're primary or secondary actions or a "guide" is not relevant. They need to meet the same contrast ratio rules we're adopting for any other UI control.

The icons within the buttons are equivalent to text, so they have to meet the 4.5:1 luminosity contrast ratio required for text.

The requirement for non-text contrast is different and applies to non-text parts of the UI, where the contrast must be at least 3:1

[afercia]

Removing the enhancement label and adding the "bug" one, as color contrast is really a very basic requirement fo any accessible project.

[karmatosed]

Just to add context, is there no change if something is revealed on hover? For example, think of a drop down. In this context these are similar as on hover they change color. I ask for information as that helps clarify.

[afercia]

Well, to be able to "hover" something I need to be able to see it first.

[bemdesign-er]

While I get the design approach to keep these controls visually out of the way until needed or triggered, for folks with vision impairments (and really that will be all of us as we age), they are getting very close to not being there at all. So if we still want to keep the current design approach (and it is an appealing design), would it be possible to provide a higher-contrast version that meets WCAG standards and users could toggle via their user profile or even the first time they use Gutenberg? Is this feasible?

[karmatosed]

@bemdesign-er do you have a suggestion for that maybe wit a screenshot or mockup?

[bemdesign-er]

On the User Profile view there would be a checkbox for toggling higher-contrast styling for Gutenberg:

And on the post editing view toolbar - a quick, easy way to toggle higher-contrast styling:

Toggling the higher contrast styling would change the styling to provide more contrast. The gray borders would be #888 or #777 or something along those lines, opacity would be reduced to .65/.75, also all buttons would be visible on block focus making it easier for users with visual impairments or even cognitive issues to better understand and "see" the editing interface. Something that would look like this:

The core idea behind this higher-contrast styling, is, while carrying on the spirit of the current design, adjust the darkness, opacity, and visibility of the editor controls to make it easier for users with visual and cognitive impairments to see the actual interface.

[hedgefield]

An interesting idea! I'd put it under the More menu in the top right where more of such options reside, but otherwise something to consider.

[afercia]

interesting idea, I'd consider to reverse the default though 🙂The default color scheme in WordPress aims to be accessible at level AA. This applies to the whole admin interface and I don't see why it shouldn't apply to Gutenberg too. Then, there are alternate color schemes users can choose from their profile page, including a "light" one that could be used for a lighter color contrast.

[karmatosed]

Whilst I understand what the option is doing I feel we've escalated to a point we maybe want to step back from if we are adding an option into 2 places. Let's go back to considering what the contrast should be here.

[joedolson]

@mtias said that "This is meant to be a very secondary shortcut for convenience..." In that case, what is the primary that this is secondary to? Where do you find the primary feature that's equivalent to this?

My impression, looking at this feature, is that these features are quick-access options for suggested or possibly frequently used blocks, although I don't actually know what's going into this tool. If they are low contrast, such that some users may never be aware of them, you're creating an interface that explicitly makes it more difficult for low-vision users to be more efficient.

Granted, this is based on guesswork concerning what those items actually represent; I'm not clear from context why they are there or what they're supposed to be.

[jasmussen]

Good feedback. We will address this issue as part of efforts to fix #7271.

[mtias]

These are being considered for removal: #10519

[tofumatt]

These features are being considered for removal and seemingly not deemed important so I'm moving this out of 5.0.

[jorgefilipecosta]

Thank you for the reporting and discussions on this issue. I'm closing the issue as it seems now the button colors rgba(10, 24, 41, 0.7); pass the AA contrast criteria for any size and the AAA criteria in the text if the font size is bold and greater than 14px or normal and greater than 18px. If my analysis is wrong, feel free to reopen the issue, and we will look further.