Posted by kat3_drx on May 10, 2010 at 9:09pm
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | shortcut.module |
| Category: | task |
| Priority: | normal |
| Assigned: | kat3_drx |
| Status: | closed (fixed) |
| Issue tags: | accessibility, shortcut, Usability |
Issue Summary
The "Edit shortcuts" link by default has a color of #bbb against a background of #666666, which fails WCAG 2.0 color contrast checking. The hover color is #fff, which passes. The shortcut menu items themselves have a color of #fff and background of #555555 which also passes. Suggest the behavior/hover standardized to match the shortcut menu items, possibly with the below patch.
I surfed the issue queue but couldn't find this addressed specifically for Shortcut, where the issue originates, but it was noted in #660576: Ensuring Proper Color Contrast for Garland for Garland.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| shortcut-color-contrast-css.patch | 1.69 KB | Idle | PASSED: [[SimpleTest]]: [MySQL] 20,254 pass(es). | View details |
Comments
#1
Whoops sorry about that, cleaner patch :D
#2
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.
#3
Per Mike's request, here are some screenshots for reference. "Patched" shows the rollover effect, from left to right, with the patch applied. "Not Patched" shows the current link rollover state, from left to right. "Example" shows the other elements in the shortcuts toolbar that the rollover effect "look" is borrowed from.
It's also worth noting that, while the link color #fff passes with a background of #555555, the rollover background of #555555 against the toolbar background of #666666 fails all luminosity tests. However, the link itself is readable. Is the 555555/666666 ratio something we also want to address?
Also yoroy, only on hover could be a potential problem for users with cognitive disabilities, or memory disorders. I think however that it's the sort of action that would be worth doing some usability testing on, to see what user reactions are.
Let me figure out why that patch won't apply...
#4
Tested, works as advertised.
Patch applied fine for me, but I rerolled it so maybe others will have an easier time.
#5
Fixed a tiny whitespace inconsistency.
#6
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.
#7
@yoroy: i see your point...the only thing I wonder is, if the dark hover background is what's used in the toolbar and in the overlay topmost bar, maybe the hover is more universal than an underline on rollover...I think your previous suggestion of adding the icon instead would solve this too though. Will try a patch of that.
#8
one more tag
#9
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!
#10
We went for the darker color cause with a lighter color it pops up to much...
But I guess we have to respect wcag
#11
Damm, sucks that we have to reverse a good design decision. But please address yoroy's point in #6
#12
Oops
#13
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).
#14
@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
#15
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
#16
The last submitted patch, editshortcutslink.patch, failed testing.
#17
Aw sorry. No time to reroll right now…
#18
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.
#19
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 ?
#20
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
#21
#22
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...
#23
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.
#24
@mgifford A short reminder, post images with any visual patch you do, makes it way easier for anyone to review (including me).
#25
The last submitted patch, shortcut-color-contrast-css-small.patch, failed testing.
#26
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
#27
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.
#28
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.
#29
#28: shortcut-color-contrast-css-small-3.patch queued for re-testing.
#30
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.
#31
#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?
#32
What, total black fails? I am not sure how changing that would look, because we applied the gray all over Drupal.
#33
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?
#34
/me opens a can of worms, so our D7 tabs have insufficient contrast?
#35
These ones seem fine.
#36
#28: shortcut-color-contrast-css-small-3.patch queued for re-testing.
#37
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.
#38
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
and from G183:
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.
#39
@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.
#40
This was already RTBC, basically we removed the design decision to make it visually less important.
#41
@mgifford, no need to put it off. @nowarninglabel came up with the answer I was looking for.
#42
Committed to CVS HEAD. Thanks.
#43
Automatically closed -- issue fixed for 2 weeks with no activity.