WCAG 2 Reaches Recommendation Status

It’s been a long time coming, but as of today the standards of accessibility expressed in the Web Content Accessibility Guidelines are officially updated.

A W3C recommendation is the most final state a document can reach in the W3C standards system, and should now be considered the standard document for accessibility, superceding WCAG 1.

A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards published by other organizations.

Although there has been a great deal of controversy over the past few years concerning the validity of the WCAG 2 revision, the final document has managed to deal with the greater proportion of problems. Not everything, certainly — but expecting perfection in such a vast area of concern is, frankly, an unrealistic concern.

Jared Smith recommends reviewing the original draft from January 2001 to make comparison — could be entertaining! However, if you’ve got limited time to spend, now is definitely the time to make certain you’re thoroughly familiar with the new standard for web accessibility. It’s actually final.

Testing Color Contrast for WCAG 1 & 2

Use the Color Contrast Spectrum Tester or compare the contrast of two colors.

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.

WCAG 1 does not, in fact, provide any specific guidelines concerning color contrast. The formulas commonly used to judge this were specified in Techniques For Accessibility Evaluation And Repair Tools, published in 2000. The document is intended to help authors conform to WCAG, but is not actually part of the WCAG document.

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.

When this article was initially written, this was more true than it is now. At the time, the limit for normal text contrast was a luminosity ratio of 5:1. The final version of WCAG, however, adjusted this to 4.5:1, which opened up additional possibilities. Nonetheless, if you look at your options using colors like #707070, you don’t have very many choices.

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 a basic tool which compares two colors, 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:

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:

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

Alternative Text for Significant Images

In the comments from my most recent article, “Supporting Standards that Support Accessibility,” a number of interesting thoughts were raised concerning the requirement (or lack thereof) of the alt attribute in HTML 5.

It’s a difficult issue.

I’ve seen numerous articles around the web which discuss the fact that HTML 5 does not require the alt attribute. To some degree, this is true: HTML 5 provides exclusions to the requirement. In situations where an image is significant but no alternative text can be provided, HTML 5 recommends that the alt attribute be left off as an indicator that the image is significant (not a purely decorational image).

It’s actually quite a bit more complicated than that — the specification describes detailed guidelines for when the alt attribute should be left off, when it should be given a value, and when it should be provided without a value.

My complaint, and the complaint of many others involved in the web standards world is against the concept of providing any reason that the alt attribute may be left off. Ian Hickson states:

Empty alt text means the image is unimportant (decorative) and should be ignored. Missing alt text means that the image is important, critical even, but that there is no fallback text provided. The user agent is expected to treat the two cases differently.

At least, that’s what the HTML5 spec says at the moment.

I believe that it is important to provide a way to distinguish the two cases above; putting both of them into the empty alt=â€?” category would be, IMHO, bad for the accessibility of the aforementioned pages.

He’s right, of course — it is quite important to distinguish between insignificant images such as decorational graphics and between significant but undescribed or undescribable images. The challenge, then, is to come up with a solution to the problem which allows the alt attribute to remain.

So…what are some possible alternatives?

The first thing that comes to mind is to add a signifier attribute. Something which indicates whether an image is significant or non-significant. This would require some revision to HTML generating tools, but certainly no greater a change than that expected for new elements. It would be best to assume a default value when the element is not provided which assumes the image is significant, for backwards compatibility.

A second possibility would be to introduce a key term available to the alt attribute which would indicate significance. This strikes me as a bad idea, since it would have relatively poor backwards compatibility, and would require selecting a term which would become unavailable as normal alt text. Nah, that’s not really going to work.

Third…I’m struggling to come up with another idea…

I’m very open to any thoughts on the subject. Problems with these ideas are welcome, as are suggestions of any off-the-wall idea you may have!

Page 1 of 11

Return to Top