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.

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.

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

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

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

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

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

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

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

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.

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.

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.

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.

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

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.

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.