Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dead_arm’s picture

dead_arm’s picture

FileSize
4.83 KB
4.5 KB

I 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: the colour that has the least contrast to the text must pass.

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:

  1. Just abandon the gradient since it is very subtle and not likely to be terribly missed
  2. no-gradient.png

  3. Take cues from the new action link styling
  4. blue-gradient.png

Accessibility group post:
http://groups.drupal.org/node/273308

More detail from W3C:
http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/G18

Bojhan’s picture

Status: Active » Closed (won't fix)

This 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.

tim.plunkett’s picture

Status: Closed (won't fix) » Active

The text should pass WCAG AA on both the lightest part and darkest part of the background gradient.

mgifford’s picture

I 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.

Bojhan’s picture

I 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.

mgifford’s picture

Ok, 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.

dead_arm’s picture

Status: Active » Needs review
FileSize
1.5 KB
5.07 KB
5.96 KB
18.52 KB
5.01 KB
6.5 KB
17.15 KB

Patch 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:
before.png
Dropbutton hover:
before-hover.png
Dropbutton open:
before-open.png

After:

Dropbuttons:
after-adjusted-gradient.png
Dropbutton hover:
after-hover.png
Dropbutton open:
after-open.png

droplet’s picture

@dead_arm,

can you list a few options to us ? Grey hover seems really bad to me.

dead_arm’s picture

@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:
underline-hover.png

mgifford’s picture

It 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.

Cliff’s picture

In < a href="http://drupal.org/node/1858206#comment-6859884">comment 6, Bojhan said:

I don't see how this violates WCAG AA. Can I get some pointers?

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.

mgifford’s picture

Issue tags: +D8UX usability

@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.

Bojhan’s picture

Wondering, what do we do on normal links?

mgifford’s picture

#10: dropbutton-1858206-10.patch queued for re-testing.

mgifford’s picture

@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:

 .js .dropbutton-widget:hover {
-  background-color: #f0f0f0;
+  background-image: none;
   border-color: #b8b8b8;
 }
+.js .dropbutton-widget:hover a {
+  text-decoration: underline;
+}

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.

mgifford’s picture

Issue tags: -Accessibility, -D8UX usability

#10: dropbutton-1858206-10.patch queued for re-testing.

mgifford’s picture

Issue tags: +Accessibility, +D8UX usability

#10: dropbutton-1858206-10.patch queued for re-testing.

tim.plunkett’s picture

Status: Needs review » Reviewed & tested by the community

Accessibility++

Bojhan’s picture

Status: Reviewed & tested by the community » Needs work

Using 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.

mgifford’s picture

FileSize
10.95 KB

Definitely 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):

Extra Underlines in Views

mgifford’s picture

Status: Needs work » Needs review
Issue tags: -Accessibility, -D8UX usability

#10: dropbutton-1858206-10.patch queued for re-testing.

mgifford’s picture

#10: dropbutton-1858206-10.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, dropbutton-1858206-10.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
Issue tags: +Accessibility, +D8UX usability

#10: dropbutton-1858206-10.patch queued for re-testing.

mgifford’s picture

CSS 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()

dead_arm’s picture

Revisiting 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:

Screen Shot 2013-07-24 at 2.42.06 PM.png

Screen Shot 2013-07-24 at 2.42.18 PM.png

Screen Shot 2013-07-24 at 2.47.19 PM.png

Screen Shot 2013-07-24 at 2.42.29 PM.png

With patch:

Screen Shot 2013-07-24 at 2.41.24 PM.png

Screen Shot 2013-07-24 at 2.41.10 PM.png

Screen Shot 2013-07-24 at 2.41.33 PM.png

Screen Shot 2013-07-24 at 2.41.38 PM.png

Status: Needs review » Needs work
Issue tags: -Accessibility, -D8UX usability

The last submitted patch, drupal-1858206-27.patch, failed testing.

dead_arm’s picture

Status: Needs work » Needs review
Issue tags: +Accessibility, +D8UX usability

#27: drupal-1858206-27.patch queued for re-testing.

Kiphaas7’s picture

It 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 :).

mgifford’s picture

This is working in most places:
Screen Shot 2013-07-27 at 9.38.57 AM.png

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:

Screen Shot 2013-07-27 at 9.39.59 AM.png

Screen Shot 2013-07-27 at 9.39.27 AM.png

Not sure where this is. I simply tested this patch with SimplyTest.me.

dead_arm’s picture

The 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?

mgifford’s picture

It just seems inconsistent.

Either way it needs feedback from the UX folks.

mgifford’s picture

27: drupal-1858206-27.patch queued for re-testing.

mgifford’s picture

Issue summary: View changes
Issue tags: +Needs usability review
Bojhan’s picture

This is super weird, it should be consistent white not having it sometimes display the gradient.

mgifford’s picture

FileSize
12.71 KB

It 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:

These should be the same

The bigger problem I think is that when tabbing through the page the down arrow isn't highlighted on focus.

mgifford’s picture

sun’s picture

Status: Closed (duplicate) » Needs work

Can't be a duplicate of itself.

mgifford’s picture

Damn.. 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...