Icons contrast fails WCAG validation

Pinged Kevin O'Leary to come up with a solution :)

Here's a patch which increases the contrast across the board, by lightening backgrounds and darkening fonts. I chose #5a5a5a as the default font color, as that makes Aloha's buttons match the default font color of the Seven theme buttons. More consistency could probably be achieved if appropriate, as AFIAK, Spark's current Aloha design was done fairly independently, and against the Seven theme (which is going to be the admin theme in 90% of cases).

WCAG results according to http://webaim.org/resources/contrastchecker/:

Normal:

Fore: #5a5a5a
Back: #efefef

Normal:
WCAG AA: Pass
WCAG AAA: Fail

Large:
WCAG AA: Pass
WCAG AAA: Pass

Active (during click):

Fore: #222222
Back: #888888

Normal:
WCAG AA: Pass
WCAG AAA: Fail

Large:
WCAG AA: Pass
WCAG AAA: Pass

Active (after click):

Fore: #353535
Back: #ababaa

Normal:
WCAG AA: Pass
WCAG AAA: Fail

Large:
WCAG AA: Pass
WCAG AAA: Pass

This particular tool didn't have a "small" size, but these buttons are at least "normal" and probably considered "large". Additionally for all these results, this is the "worst-case" situation, against the least-contrasting part of the button. In actuality, readability will be slightly increased because the contrast increases in the middle of the gradient.

In any case, according to the tests we've got at *least* AA on all buttons, probably AAA considering the gradient and font size.

I deployed this to http://spark.webchick.net/8.x for testing. Here is a screenshot showing "at rest," "depressed," and "active" styling:

Looks great to me, but leaving NR to get some other opinions.

I know that this represents (a small amount) of scope creep but in an effort to make Accessibility not be an enemy of design I am going to suggest a system-wide toggle that loads a "high contrast" style sheet (hi-con.CSS) for visually impaired users.

It's effects would be something like:

• All WYSIWYG icons turn to #000
• All toolbar icons turn to #000
• All toolbar text turns to #000
• All interface text changes to #000
• Edit-submit button backgrounds darken significantly
• and probably a few additional overrides.

I will write this CSS file myself and pass it to Jesse Beach for code review.

I'm not sure where to present the toggle to the user but it should be prominent, discoverable and available on any admin page. It should also be set and remembered on a per user basis.

This works but really guts many of the subtleties of the design. See my comment on global toggle.

@tkoleary did you mean to remove "needs accessibility review" or was that just a timing issue?

Did you also change the active background gradient? It seems a little hard now. Let me check with zhe a11y team

Yes, it passes the WCAC now, I would think it's probably more readable than before.

Accessibility not be an enemy of design I am going to suggest a system-wide toggle that loads a "high contrast" style sheet (hi-con.CSS) for visually impaired users.

On Mac OS X at least, turning up the contrast to 90% already yields something very close to a high-contrast mode for the buttons. Everything is readable. I don't think there should be a high-contrast mode specifically for Aloha. Leave that to a theme that can provide a specifically good-looking high-contrast appearance across the board.

@quicksketch - agreed.

I haven't run the color combinations through http://www.dasplankton.de/ContrastA/ but they look good to me.

Thanks a lot for the patch @quicksketch! :) Much appreciated!

@tkoleary: I'd much rather not go the scope creep route, especially if that means introducing the global toggle you're referring to (which suggests that it'll affect more than just Aloha's UI). Why not keep it simple, and ensure the contrast is high enough at all times? Imagine an anonymous user commenting on some site, how could we possibly expect that user to know about our toggle? If the UI does not have sufficient contrast out of the box, (s)he would most likely just forgo leaving a comment at all.

Not yet committing this to hopefully reach some degree of concensus, but let's try to keep it simple :)

Not really interested in a switcher into 'accessible' styles, to me that seems like a super slippery slope. Let's just make sure that the site meets WCAG 2.0 for everyone.

Besides, many people that could benefit from appropriately contrasted fore/back colours don't have any idea about high contrast / low contrast, they just know "that thing is hard to see".

Everett++

@Bojhan @quicksketch I had a long talk with Wim and Angie about this and the upshot was that even if a global toggle was acceptable under WCAG (questionable) the implementation of it is too much effort right now. So i'm on board with committing this patch.

@quicksketch thanks for doing this.

Great, thanks @tkoleary :)

Committed @quicksketch's patch as-is, the only changes being that I lowercased the hex colors he used (as Drupal core does).

- D8: http://drupalcode.org/project/aloha.git/commit/99b4c69
- D7: http://drupalcode.org/project/aloha.git/commit/cbfd382