Some time ago, while pondering whether web accessibility posed limitations on design, the thought occurred to me that there are presumably some colors which simply cannot be used for text or text backgrounds in any site.

The nature of the Web Content Accessibility Guidelines (WCAG) specifications of color contrast fairly well ensures that some colors in the middle range of the spectrum (in hexadecimal, generally between #666666 and #999999) simply won’t be compatible with any other color.

My first thought on this point was to create a chart of colors which simply couldn’t be used in these contexts. I decided against this, on the grounds that it didn’t really seem all that valuable to me. But the thought of viewing color contrast problems in a different way than most color contrast checkers stuck with me.

It seems that most color contrast checking tools work in one of two ways: they either take a webpage and check the contrast factors between text and background on that page, or they allow you to enter a pair of colors and find out how they mesh up. Since this article was authored, I’ve created this basic tool as well. Evaluate contrast between two colors.

What I’ve done instead is set up a color contrast checker which only requires you to enter one color, then displays a selection of possible color combinations using that color. It’s pretty straightforward: you can choose to view results ordered according to WCAG 1’s color brightness and color difference tests or according to WCAG 2’s contrast ratio algorithm. Either way, all three factors are displayed, providing a good sense for how the two systems differ.

The results can be quite interesting. Compare the results for #888888 under WCAG 1 and under WCAG 2, for example:

• #888888 Tested for Color Brightness and Color Difference
• #888888 Tested for Luminosity Contrast

Altogether, I’m hoping that this tool provides an interesting way to approach color contrast issues and to view the differences between WCAG versions 1 and 2.

Resources:

• Explanation of luminosity contrast ratio algorithm (Gez Lemon)
• WCAG 2, definition of relative luminance
• WCAG 2, definition of contrast ratio
• WCAG 2, understanding Guideline 1.4
  • 1.4.3 Contrast (minimum)
  • 1.4.6 Contrast (enhanced)
• List of color contrast checking tools (Roger Johansson)

Color Comparison Formulas

Color brightness formula: (must be greater than 125)

((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000

Color difference formula: (must be greater than 500)

(maximum (Red value 1, Red value 2) - minimum (Red value 1, Red value 2)) + (maximum (Green value 1, Green value 2) - minimum (Green value 1, Green value 2)) + (maximum (Blue value 1, Blue value 2) - minimum (Blue value 1, Blue value 2))

Contrast Ratio with Relative Luminance formulas: (greater than 3:1 for print sizes over 14pt Bold equivalence or 18pt normal, greater than 5:1 for smaller text)

(L1 + 0.05) / (L2 + 0.05) where L1 = 0.2126 * R1 + 0.7152 * G1 + 0.0722 * B1 on the RGB values of the lighter color and L2 = 0.2126 * R2 + 0.7152 * G2 + 0.0722 * B2 on the RGB values of the darker color.

Every once in a while, somebody mentions to me how they’re concerned because their (or my) site didn’t “pass” some online accessibility evaluator or another. This always opens up the conversation for one big, complicated issue: why automated accessibility testing just doesn’t work.

This isn’t to say that automated testing doesn’t have a place; but it should never be considered the deciding factor for accessibility.

The Functional Accessibility Evaluator from the University of Illinois at Urbana-Champaign was pointed out to me recently. Naturally, I figured it was worth a look. In fact, it’s very interesting. (It has problems, but I’ll get to those.)

Read more: An Example of Automated Accessibility Testing

At least, in the final reckoning.

Something which comes up over and over in my work is the tendency of clients to request design changes which I don’t particularly care for. This isn’t to say that they’re ugly, per se — after all, the fact that I don’t like them isn’t actually equal to “ugly.”

Early on, I would argue with clients concerning these design changes — try and get them to see my perspective, etc. But the fact is that aesthetics are not objective. Opinion matters; and it’s ultimately the client’s decision.

Now, I only argue with decision which cause problems. You want that to be blue instead of green? Fine. Doesn’t matter to me that it’s going to clash with the rest of the color scheme. But you want that text to be blue against an orange background? That, I won’t do. That’s the kind of decision which will render the text unreadable — and I’m not willing to do it.

Occasionally in my consulting practice I encounter designers (or stories about designers) who are so wrapped up in control over their design that they barely consider the client’s needs, let alone the needs of usability and accessibility. That’s unfortunate; since in the end, what your website looks like just barely registers for many visitors.

I sincerely believe (unscientifically) that most visitors only notice website design in one of three ways:

1. The design prevents them from effectively using the site.
2. The design is absolutely spectacular.
3. The design is absolutely horrific.

Do you really want your design to be attracting attention? Certainly not for reasons numbers 1 and 3, and although the second reason is positive, it’s not necessarily best for every site. Incredible design doesn’t necessarily support your business in the best way; it could just get in the way. This can’t be decided universally, of course — and it’s never a bad thing to strive for a great design.

It’s hard to ask questions about whether people noticed the design of a site. After all, it’s rather a quantum query: once you’ve asked, they will observe. The act of asking changes the experience of the visitor. Even in a usability test, it’s hard to identify this observation. Even though you can set up the scenario more effectively, if your testers are still aware that they are testing the site, they will tend to be more observant than otherwise.

You can’t TELL somebody to just “act normally” during a test, unfortunately. It doesn’t work that way….

Nonetheless, the rules I will work to avoid are clear: don’t make it horrible, and don’t let it get in the user’s way. Otherwise, what it looks like is open territory. I’ll try to make it look as good as I can, but if a client wants a change — they’ll get it.