New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block actions not highly visible #7177

Open
anevins12 opened this Issue Jun 6, 2018 · 19 comments

Comments

Projects
None yet
10 participants
@anevins12
Contributor

anevins12 commented Jun 6, 2018

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:

example

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 comment has been minimized.

Contributor

mtias commented Jun 22, 2018

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

This comment has been minimized.

Member

karmatosed commented Jun 22, 2018

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

This comment has been minimized.

Contributor

anevins12 commented Jun 24, 2018

@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 comment has been minimized.

Member

karmatosed commented Jul 15, 2018

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

This comment has been minimized.

hedgefield commented Jul 16, 2018

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

This comment has been minimized.

Contributor

afercia commented Jul 16, 2018

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

This comment has been minimized.

Contributor

afercia commented Jul 17, 2018

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

@karmatosed

This comment has been minimized.

Member

karmatosed commented Jul 18, 2018

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

This comment has been minimized.

Contributor

afercia commented Jul 18, 2018

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

@bemdesign-er

This comment has been minimized.

bemdesign-er commented Jul 25, 2018

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

This comment has been minimized.

Member

karmatosed commented Jul 25, 2018

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

@bemdesign-er

This comment has been minimized.

bemdesign-er commented Jul 31, 2018

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

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

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:
editor-toolbar-higher-contrast

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

This comment has been minimized.

hedgefield commented Jul 31, 2018

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

This comment has been minimized.

Contributor

afercia commented Jul 31, 2018

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

This comment has been minimized.

Member

karmatosed commented Jul 31, 2018

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

This comment has been minimized.

joedolson commented Jul 31, 2018

@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

This comment has been minimized.

Contributor

jasmussen commented Oct 11, 2018

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

@mtias

This comment has been minimized.

Contributor

mtias commented Oct 12, 2018

These are being considered for removal: #10519

@tofumatt

This comment has been minimized.

Member

tofumatt commented Nov 16, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment