Shortcut "Edit shortcuts" link has insufficient color contrast ratio

It's been noted before that this should use the contextual links-style gear icon showing on:hovering the shortcuts bar.
Leaving that aside, would it be ok to not show the link by default and only show it on hovering the shortcuts bar? Might become distracting though.
Also, the latest patch doesn't apply for me.

Tested, works as advertised.

Patch applied fine for me, but I rerolled it so maybe others will have an easier time.

Fixed a tiny whitespace inconsistency.

Lets not re-use the same dark background like this. It's not a shortcut itself, so try to not make it look like one. Suggest to make the hover state add an underline instead.

one more tag

I wanted to test this patch. It applied well. I really wish I'd taken a photo rather than a screenshot. With contrast it's not just an an accessibility thing for those people who have vision impairments, but also for those of us who sometimes go outside with our laptops and have to squint to see through the reflection from the sun! The patch in 5 is much easier to see!

+1 for this patch!

We went for the darker color cause with a lighter color it pops up to much...
But I guess we have to respect wcag

Damm, sucks that we have to reverse a good design decision. But please address yoroy's point in #6

Oops

Ok, @Bojhan, what do we need to do to make it RTBC? When a good design decision has accessibility problems is there a way to make a compromise? how do we improve the visibility of the site for everyone (even on items that you don't want to be super prominent).

@mgifford Well, I don't think we can compromise here? Unless you find a saturation that is a bit darkened, but not dark enough to validate.

Regarding what to do to make it RTBC, adress yoroys point in #6 about losing the darkening background

The 'darkest' grey for the link that scores a "4.52:1 (AAA pass for large text; AA for regular text) and for difference in brightness a 126 (pass) is #e4e4e4, which is only a tiny bit darker than plain white.
Using an underline for the hover state. Does apply the black background box when active. Screenshot of normal state: http://skitch.com/yoroy/dgpb7/firefox

Aw sorry. No time to reroll right now…

A reroll...

ps: I rerolled this with a cleaned up shortcut.css file (I just added the small changes yoroy proposed)

Screenshot to see results.
Feel free to reroll without my local clean-up if necessary.

After reviewing my own patch...

 div#toolbar a#edit-shortcuts {
+  -moz-border-radius: 5px;
+  -webkit-border-radius: 5px;
+  border-radius: 5px;

Why do we need a border ?

Thanks! A border-radius is needed to get the rounded corners on the black background when this link is the active link: http://skitch.com/yoroy/dgxcb/welcome-to-d7-d7

1)

Seems like a drastic UI color change for every shortcut ...
Cause now, every active shortcut is black...

*** My brain isn't used to it yet ***

EDIT: this is OK, currently it's also black. I think I was braindead that day

2)

Are those active toolbar tabs color valid???
Cause I don't see a lot of contrast there either...

I'm trying to figure out if there's a way to introduce basic color contrast with as little disturbance as possible to the rest of the design.

Using http://www.webaim.org/resources/contrastchecker/ we can easily see where there are problems with specific combinations.

Some of these patches have started to get pretty complicated. The main problems are these two items:

div#toolbar a#edit-shortcuts {
   float: right;
   padding: 5px 10px 5px 5px;
   line-height: 24px;
  color: #bbb;

...

 div#toolbar a#edit-shortcuts:focus,
 div#toolbar a#edit-shortcuts:hover,
 div#toolbar a#edit-shortcuts.active {
   color: #fff;

And the fact that if you make the background behind the edit-shortcuts link darker it breaks the style of the other links.

So I'm tossing out a hopefully simpler version to get folks thinking and hopefully bring this simple patch to RTBC.

@mgifford A short reminder, post images with any visual patch you do, makes it way easier for anyone to review (including me).

http://skitch.com/yoroy/dpecs/before
http://skitch.com/yoroy/dpepx/before-hover

http://skitch.com/yoroy/dpepi/after
http://skitch.com/yoroy/dpepa/after-hover

That hover is a no-go: shouldn't mimic actual shortcut link behavior
I would suggest a simple underline on hover

Ok, if it isn't supposed to mimic the shortcut link it makes it easier for sure. This is a bit more of what I was thinking. However, it may still be too close to the existing shortcut links.

But heck, if an underlined link works just as well for usability. It should be fine for accessibility.

This is a much simpler patch to achieve this.

@Bojhan, thanks for the reminder about the images. I've been trying, but had some server issues.

#28: shortcut-color-contrast-css-small-3.patch queued for re-testing.

I am thinking, instead of going white can we go the opposite? dark?

Sorry, for exploring this late in the game - but think it could work really well.

#000 on #666 still fails for normal sized text according to http://webaim.org/resources/contrastchecker/

That would all change if we could bring the background color down to #767676.

Any chance we could do that?

What, total black fails? I am not sure how changing that would look, because we applied the gray all over Drupal.

A #767676 or #757575 background can either have a #000 or #fff as a text color, but not all grays can do that.

So back to the patch in #28?

/me opens a can of worms, so our D7 tabs have insufficient contrast?

These ones seem fine.

#28: shortcut-color-contrast-css-small-3.patch queued for re-testing.

This is an interesting issue. Basically, we're trying to be sure that there is enough contrast between background and the inactive element for the user to know that the element is there — or perhaps only that an element is there — as well as enough contrast between the active and inactive states for the user to perceive the change from one to the other.

But it could be that these levels of contrast could be lower than the acceptable levels for an active element from its background. A perceivable difference is not the same thing as a readably perceivable difference, but I don't know that WCAG addresses the issue.

I'll do some research into this. We do need to know a valid answer, because it's essential information for all themers. And if anyone wants to work offline with me to figure this out, ping me.

From http://webaim.org/blog/wcag-2-0-and-link-colors/ which refers to http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G183

It’s important to note that according to G183, focus/hover states for links must have a non-color designator. This typically means that you would add the underline style to the link when it is hovered or tabbed to. This is a Level A requirement.

and from G183:

With this technique, a relative luminance (lightness) difference of 3:1 or greater with the text around it can be used if additional visual confirmation is available when a user points or tabs to the link. Visual highlights may, for example, take the form of underline, a change in font style such as bold or italics, or an increase in font size.

So, my suggestion is to follow #28, have an underline link on hover, and if you still want a color change as well on active/hover state, then make it #bbbcbb which meets the minimum ratio as it is 3.01:1.

@nowarninglabel are you willing to mark this RTBC?

@Cliff - if more research is required should we put this off to D8? It's harder to get in now the beta is out.

This was already RTBC, basically we removed the design decision to make it visually less important.

@mgifford, no need to put it off. @nowarninglabel came up with the answer I was looking for.

Committed to CVS HEAD. Thanks.