Make WordPress Core

Opened 14 years ago

Closed 11 years ago

#16103 closed defect (bug) (wontfix)

Blue Admin theme doesn't have enough contrast

Reported by: jorbin's profile jorbin Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Accessibility Keywords: ui-feedback has-patch
Focuses: Cc:

Description

The beautiful blue theme has a few parts that lack sufficient contrast to be useable by someone with color deficiencies. Specific parts to follow.

See attached screen shots to get a better idea. Highlighted areas lack contrast.

Attachments (4)

Dashboard ‹ TEST — WordPress_1294199529302.png (199.0 KB) - added by jorbin 14 years ago.
Add New Post ‹ TEST — WordPress_1294199794206.png (125.6 KB) - added by jorbin 14 years ago.
16103.diff (390.6 KB) - added by cliffseal 12 years ago.
16103-nomin.diff (1.4 KB) - added by cliffseal 12 years ago.

Download all attachments as: .zip

Change History (30)

#1 @jorbin
14 years ago

  • Milestone changed from Awaiting Review to Future Release

#2 @saracannon
14 years ago

  • Cc sararcannon@… added

#3 @jane
14 years ago

Please cite which regulations you're using, and suggest alternate color values that would achieve sufficient contrast. Otherwise, will just wait until we get an accessibility eval when 3.1 comes out.

#4 @cgrymala
14 years ago

Obviously I can't speak for jorbin, but, reviewing the attachments provided and comparing them against the WCAG 2.0 AA guidelines, the text that is currently set to a color value of #999 (#the-comment-list .comment-item h4) should have a color value of #737373 or darker in order to have a contrast of at least 4.5:1.

As far as I can tell, the link text in wp-head is acceptable under all WCAG standards, so I'm not sure why jorbin highlighted that twice.

Keeping to the WCAG 2.0 AA standards; I couldn't find a suitable replacement for the color used on #dashboard_right_now .waiting (which uses a text color of #e66f00), but the #dashboard_right_now .spam (which currently uses red) could change to #e00 and would meet the threshold of 4.5:1.

#5 @ctsttom
13 years ago

  • Cc me@… added

Is this an April fools?

Why does this need to be fixed? Rather than modifying a little used theme to make it so that people with colour blindness can use it, why don't the colour blind people just use the default theme like a large number of other WordPress users?

I am sorry to be so blunt but this would be a waste of anyones time to fix this and its only an issue if you have a disability and are also stupid enough to use the blue theme knowing that you have this disability. The percentage of these two use cases stacked is so low that if it was the percentage of Internet Explorer 6 users we would have dropped support ages ago.

#6 @jane
13 years ago

@ctsttom: We take accessibility seriously, despite the fact that we always have room for improvement. The attitude in your comment is rude, and not in keeping with our dedication to meeting basic accessibility standards. Small improvements like this may not always rise to the top of the priorities list, but they are still important, or we would have closed the ticket.

#7 @ctsttom
13 years ago

@jane: I agree with you that accessibility is a serious issue, I am classed myself as having a disability however you are trying to make something that is inherently incompatible with a disability work when there is a perfectly good alternative, default theme.

This is like saying we need to make the stairs flatter for those who are wheel chair bound because they prefer to use the stairs even though its hard/impossible for them to use over the perfectly good ramp right next to it which is the way most people get into the building.

I am sorry if I offended anyone but I feel that while accessibility is a important issue and this ticket should be raised I feel that equally this doesn't need to be fixed because its similar to the above analogy.

However discussion is good, I just feel this is a wontfix issue.

#8 @jane
13 years ago

@ctsttom: Stairs are inherently different from elevators. They gray and blue color schemes are equal in our eyes, not two separate animals. They are meant to have the same exact level of contrast, we just messed up. Let's not turn this into something it's not.

#9 @ctsttom
13 years ago

@jane: I appreciate your opinion and I am sure someone will fix this eventually anyway however I was just emphasising that the work seems unnecessary, however as you put it lets leave it here for the next person to decide if they want to fix it.

#10 @jane
13 years ago

@ctsttom Unnecessary means it is the way we want it as it is, or that it's being redone on another ticket. This one is not unnecessary, it's just not a high priority. The distinction makes a difference as we manage the queue.

@cliffseal
12 years ago

#11 @cliffseal
12 years ago

I went through and adjusted the specific colors pointed out by @jorbin in his screenshots to have a 4.5:1 contrast ratio (to suit WCAG 2.0 AA, as mentioned by @cgrymala). I also checked these same colors against the default gray scheme (some of which needed some minor tweaking).

#12 @cliffseal
12 years ago

  • Keywords ui-feedback has-patch added

#13 follow-up: @MikeHansenMe
12 years ago

  • Cc mdhansen@… added

@cliffseal thanks for providing a patch but we need the non-minified files altered then they will be minified automatically.

#14 in reply to: ↑ 13 @cliffseal
12 years ago

  • Cc cliff@… added

Replying to MikeHansenMe:

@cliffseal thanks for providing a patch but we need the non-minified files altered then they will be minified automatically.

Sure thing, @MikeHansenMe. They were included with the first patch, but the latest one is sans min files.

#15 @unknowndomain
12 years ago

  • Cc me@… removed

#16 @sabreuse
12 years ago

+1 for cliffseal's patch. Also, note that several of the areas highlighted at the top of the thread no longer apply: after cliffseal's changes, let's close this and move any contrast concerns with the current admin design to a new ticket.

#17 @SergeyBiryukov
12 years ago

  • Milestone changed from Future Release to 3.6

#18 follow-up: @helen
12 years ago

16103-nomin.diff does things to gray, and only one thing specifically to blue (changing the background color of the count bubble on an active admin menu item).

  • The editor.css change makes it more difficult to discern which is the active tab. Does it need to be that much darker? Note that blue uses a different color entirely, and so that change doesn't actually fit with this ticket.
  • For the title placeholder, the change is too dark to really tell it apart from entered text. If we change it, it should be changed to match HTML5 placeholder coloring in Webkit, which is #9a9a9a.
  • The "Right Now" color changes seem a bit arbitrary. Is there another red in the admin that we can use? Also, the yellow color no longer reads yellow/pending/caution to me.

#19 in reply to: ↑ 18 @cliffseal
12 years ago

Replying to helen:

16103-nomin.diff does things to gray, and only one thing specifically to blue (changing the background color of the count bubble on an active admin menu item).

What I did was adjust foreground color based on the existing background color, tweaking the tint/hue of each until I hit at least 4.5:1 contrast on both admin themes. I agree with your assessments, but just went the pragmatic route here to get things moving.

Last edited 12 years ago by cliffseal (previous) (diff)

#20 @ctsttom
12 years ago

  • Cc me@… added

#21 @esmi
12 years ago

If we change it, it should be changed to match HTML5 placeholder coloring in Webkit, which is #9a9a9a

That's still too light / low in contrast. What about using #277fa9? The blue (which should be in roughly same hue as the blues used elsewhere) should distinguish the placeholder text from entered text.

The "Right Now" color changes seem a bit arbitrary. Is there another red in the admin that we can use?

What about just dropping it to #c00? Are there color palettes anywhere for admin CSS skins?

Also, the yellow color no longer reads yellow/pending/caution to me.

Best I could do is #b55700. The problem is that as you increase the contrast to the accepted 4.5:1, you enter into the browner shades.

#22 follow-ups: @esmi
12 years ago

I've been giving this admin skin some more thought and I've come to a fairly heretical conclusion regarding the contrast issues.

Forget about them!

Why? Because there is a choice of skins, so no one is forced to use the blue skin. To my mind, it would make sense to focus on ensuring that all elements in the grey skin meets the contrast requirements and deliberately keep this as a low-contrast skin. A significant number of dyslexic users actually prefer low contrasts (ie significantly lower than those referenced in WCAG), so there are real benefits to doing nothing in this particular case.

#23 in reply to: ↑ 22 @saracannon
12 years ago

Replying to esmi:

To my mind, it would make sense to focus on ensuring that all elements in the grey skin meets the contrast requirements and deliberately keep this as a low-contrast skin.

Interesting that you mention that: the idea has been tossed around that the second admin skin should be really high contrast - even greater than the standard and made just for people who need it. I'd hate to see the lovely blue disappear though

#24 @esmi
12 years ago

I don't see why a high contrast skin should necessarily have a higher priority than a low-contrast one. Last time I crunched the numbers, there were actually more potential dyslexic users than visually-impaired ones (based on stats at that time).

That said, I'd love to see core ship with a default skin plus at least high and one low contrast skin.

#25 @ryan
12 years ago

  • Milestone changed from 3.6 to Future Release

#26 in reply to: ↑ 22 @helen
11 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to esmi:

I've been giving this admin skin some more thought and I've come to a fairly heretical conclusion regarding the contrast issues.

Forget about them!

Why? Because there is a choice of skins, so no one is forced to use the blue skin. To my mind, it would make sense to focus on ensuring that all elements in the grey skin meets the contrast requirements and deliberately keep this as a low-contrast skin. A significant number of dyslexic users actually prefer low contrasts (ie significantly lower than those referenced in WCAG), so there are real benefits to doing nothing in this particular case.

I actually find this to be quite a compelling argument, and thus I am going to close this ticket.

Note: See TracTickets for help on using tickets.