Discovered this issue in #1806022: Views' text color does not have sufficient contrast, and the contrast of the button's white background with gradient on both white and the even table row background-color in Seven does not pass.
Comment | File | Size | Author |
---|---|---|---|
#37 | on-focus-on-hover.png | 12.71 KB | mgifford |
#31 | Screen Shot 2013-07-27 at 9.38.57 AM.png | 25.86 KB | mgifford |
#31 | Screen Shot 2013-07-27 at 9.39.59 AM.png | 40.76 KB | mgifford |
#31 | Screen Shot 2013-07-27 at 9.39.27 AM.png | 42.11 KB | mgifford |
#27 | drupal-1858206-27.patch | 1.5 KB | dead_arm |
Comments
Comment #1
dead_armThis is a child of #1824634: [meta] Dropbutton accessibility issues
Comment #2
dead_armI asked in the groups.drupal.org accessibility group how to test the contrast of text on gradient backgrounds, and they were very helpful.
To quote dewh2o:
So in the case of dropbutton, the blue link color (#0074BD) passes the top of the gradient which is white (#fff), but does not pass the bottom half of the gradient which is light grey (#E7E7E7). The dropbutton hover state background color (#F0F0F0) also does not pass.
Two suggestions I have are either to:
Accessibility group post:
http://groups.drupal.org/node/273308
More detail from W3C:
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G18
Comment #3
Bojhan CreditAttribution: Bojhan commentedThis is a won't fix, the gradient is solely for decorative purposes. As long as the link and dropdown icon pass WCAG, we should be fine.
Comment #4
tim.plunkettThe text should pass WCAG AA on both the lightest part and darkest part of the background gradient.
Comment #5
mgiffordI do agree that we have to consider the lightest color for what would be considered the background for the text. It would be reasonable to make an exception if the light color was far enough away from the text that it wouldn't overlap.
EDIT: Text should be WCAG 2.0 AA on hover & focus too.
@Bojhan, what do you think of just adopting the pattern from the action link styling. I think it's easier to see & makes it more consistent.
Comment #6
Bojhan CreditAttribution: Bojhan commentedI don't see how this violates WCAG AA. Can I get some pointers?
Using action link styling is a bad idea, the idea is that the action link stands out if we use the style for all table operations we lose that affect.
Comment #7
mgiffordOk, good to know the rational for the action link pattern.
Essentially you have to work from both extremes of the gradient and consider that the background in the evaluation.
Ultimately it matters what the color is around the text. I guess one could evaluate the color of the pixel outside the text (which would be somewhere between the two extremes) and use that as a value. However, these buttons aren't very big and there's really not much space.
Hope this helps.
Comment #8
dead_armPatch attached adjusts the gradient bottom color so that it passes, and uses a grey background with white text for the hover state. Open state is the same and still passes.
Before:
Dropbuttons:
Dropbutton hover:
Dropbutton open:
After:
Dropbuttons:
Dropbutton hover:
Dropbutton open:
Comment #9
droplet CreditAttribution: droplet commented@dead_arm,
can you list a few options to us ? Grey hover seems really bad to me.
Comment #10
dead_arm@droplet The original dropbutton does have a grey hover already, but it is much lighter which is why it doesn't pass WCAG AA. Using the new actions link pattern was ruled out in #6, but I think another solution could just be removing the gradient on hover and underlining the text.
Underline hover:
Comment #11
mgiffordIt might be possible to just add the grey to the right half of the button. That way it wouldn't interfere with reading the text, but would still be very visible.
Comment #12
Cliff CreditAttribution: Cliff commentedIn < a href="http://drupal.org/node/1858206#comment-6859884">comment 6, Bojhan said:
Bojhan, you raise a question that I've often heard. There is no specific mention of this situation in WCAG 2.0 or its supporting materials themselves, so I'm going to suggest to the respective W3C WAI (Web Accessibility Initiative) working group that they add an example of such a failure to Understanding WCAG 2.0.
To answer your question, let's think of it this way: Can a page, or even just a button, conform with WCAG 2.0 Success Criterion 1.4.3 at Level AA if part of the page, or button, fails?
Of course not. The point of the accessibility guidelines is to afford people with a disability an experience equivalent to that of people who lack that disability. In this case, people who lack a visual impairment see clear text against a gradient, whereas people who have the level of disability that this level of conformance is intended to address see clear text at one end of the gradient and nothing at its other end. And seeing only the top half or two-thirds or seven-eighths of the word in the button clearly isn't an equivalent experience.
If we want to claim conformance at Level AA, we must ensure that all of the text on the button is perceivable to the degree defined by the success criteria for Level AA.
Comment #13
mgifford@Bojhan what do you think of the underline + color change in #10? Perhaps just the underline? Perhaps the gradient could be darkest in the bottom right corner and fade to white by the text. These are all possible.
Comment #14
Bojhan CreditAttribution: Bojhan commentedWondering, what do we do on normal links?
Comment #15
mgifford#10: dropbutton-1858206-10.patch queued for re-testing.
Comment #16
mgifford@Bojhan, I need to make sure I understand your question.
With a background color of #fff we can get away with a foreground color like #757575
With the light grey #f0f0f0 we need a darker image for color contrast like #656565
This is the same issue for normal links (for hover, focus, active or normal links colors).
I think the pieces of this that concern you are:
Removing the light grey background-color increases contrast & adding the text-decoration: underline; makes it more clearly on focus. Speaking of which, it should probably be
.js .dropbutton-widget:focus a
as we want this clearly visible to keyboard only users too.Comment #17
mgifford#10: dropbutton-1858206-10.patch queued for re-testing.
Comment #18
mgifford#10: dropbutton-1858206-10.patch queued for re-testing.
Comment #19
tim.plunkettAccessibility++
Comment #20
Bojhan CreditAttribution: Bojhan commentedUsing underline here seems fine, its what we normally use for links. However this patch is bugged, when I hover the dropbutton all links get a underline and not just the row I am hovering. Clearly fixing one a11y bug, should not regress another?
@mike please find me on Skype, to discuss this.
Comment #21
mgiffordDefinitely good to talk about this. I didn't get an underline under all links (just the box selected). Anyways, let's see if we can find a solution that works. I would have thought this was ok (as it was only the dropdown text that was affected):
Comment #22
mgifford#10: dropbutton-1858206-10.patch queued for re-testing.
Comment #23
mgifford#10: dropbutton-1858206-10.patch queued for re-testing.
Comment #25
mgifford#10: dropbutton-1858206-10.patch queued for re-testing.
Comment #26
mgiffordCSS changes can't cause this failure:
Link with label Test Operation: CV$6^yaG found. Other EntityOperationsTest.php 54 Drupal\system\Tests\Entity\EntityOperationsTest->testEntityOperationAlter()
Comment #27
dead_armRevisiting this issue, I found that the default for seven link hover is a text underline, and in views_ui.admin.theme.css there is a reset removing
text-decoration: underline
as a hover state. The attached patch brings the ui dropbutton more in line with core, as it also restores the underline hover state to regular links in Views UI, which core also has. The patch still removes the gradient on hover for higher contrast.Re: a:focus from #21, the focus state in core is
outline: thin dotted
from normalize.css, so we may not need to add an additional underline.Currently:
With patch:
Comment #29
dead_arm#27: drupal-1858206-27.patch queued for re-testing.
Comment #30
Kiphaas7 CreditAttribution: Kiphaas7 commentedIt could be the crappy screen I'm using, but I can't see the difference between
#f3f5ee
and#ffffff
. Even fired up photoshop to compare the colors.In other words, if these are the two colors for the gradient and the gradient is barely visible, why not replace it with a solid color background? Saves 3 lines of css.
... Unless it is my crappy monitor and others can see the gradient :).
Comment #31
mgiffordThis is working in most places:
But #overlay=admin/structure/types/manage/article/fields if you move off the hover over for a fraction of a second there is still the old gradation in place. This should just be cleaned up for consistency:
Not sure where this is. I simply tested this patch with SimplyTest.me.
Comment #32
dead_armThe patch intentionally only removes the gradient on hover. Is the suggestion that there should also not be a gradient present when the dropbutton is open but not hovered?
Comment #33
mgiffordIt just seems inconsistent.
Either way it needs feedback from the UX folks.
Comment #34
mgifford27: drupal-1858206-27.patch queued for re-testing.
Comment #35
mgiffordComment #36
Bojhan CreditAttribution: Bojhan commentedThis is super weird, it should be consistent white not having it sometimes display the gradient.
Comment #37
mgiffordIt seems to work alright for me now. It is like a hover-over effect.
Perhaps the problem was tied to Overlay, but right now without focus it has less contrast.
There is also a problem because the on focus and on hover effects should be the same:
The bigger problem I think is that when tabbing through the page the down arrow isn't highlighted on focus.
Comment #38
mgiffordMarking as a duplicate of #1858206: Dropbutton background with gradient does not meet WCAG AA standard.
Comment #39
sunCan't be a duplicate of itself.
Comment #40
mgiffordDamn.. Sorry @sun #1989470: Dropbutton style update for Seven..
Kinda funny that I could add a node as a related story to itself without a warning too...