If you’ve already read what I’ve had to say about the earlier versions of WCAG 2.0 – from my initial dislike of the 2006 version, through to my acknowledgement that the 2007 version had improved immeasurably, then there’s going to be a certain amount of overlap here.

WCAG 2.0 has now reached Candidate Recommendation status which means — more or less — that people believe that it is ready to be used but as it is not being used enough in live implementations it doesn’t get shifted to a formal Recommendation just yet, in case it turns out to be unreasonable or inappropriate in practice. So we are in the rather odd situation where we need people to adopt WCAG 2.0 before it can become a formal standard.

That might sound odd, but I hope to convince you (and myself) that it’s a job that is worth undertaking. You see, I’ve looked at the previous versions in a great deal of detail, but I’ve not really looked at the Candidate Recommendation yet, despite its publication at the end of April. So I intend to put that right now.

What is WCAG About?

Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees and combinations of disabilities. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.WCAG 2.0

Got that? This is about to help make content more accessible to those with disabilities. There are reasons why you might want to make your content standards compliant, easily usable to anyone, and running across all sorts of platforms, not requiring particular plugins and so on, but that isn’t what this is about. This is about providing access to people with disabilities. That is what comes first.

It is built around four principles: that web pages should be perceivable, operable, understandable and robust. These in turn break down into guidelines from which are derived the success criteria that you will be ultimately required to test your site against.

The main WCAG 2.0 document is accompanied by three companion documents: the WCAG 2.0 quick reference (which in practice is the one I expect people will end up referring to on a daily basis), the Understanding WCAG 2.0 document and the Techniques for WCAG 2.0 document, where techniques are described that will enable you to pass certain success criteria.

Programmatically Determined and Accessibility Supported

Apart from reminding me of the Michael Franti song ‘Listener Supported’, these are two very important concepts in WCAG 2.0 which I’m going to attempt to explain in my own words and therefore probably cock it up entirely. Bear with me…

A piece of information which may be programatically determined is not necessarily visible to someone browsing a web page, but that information is included within the page in such a way that the browsers and/or assistive technologies used to access the page can get that information. For example, if you use the scope attribute with a th element, you tell the browser whether that header should be associated with all of the items in that particular row, or with that column. Or if you explicitly associate a label with its control, that can again be programmatically determined.

WCAG 2.0 goes to great lengths to avoid tying itself down to one particular technology in the way that WCAG 1.0 did. In one sense this is a crucial step forward: it means WCAG 2.0 is much less likely to be dated by the introduction of new technologies in the way WCAG 1.0 was. WCAG 1.0 by default dislikes technologies such as flash, whereas WCAG 2.0 doesn’t care what technology you use, as long as it is accessibility supported, although that technology neutral language quite often can be more difficult to follow!

Accessibility Supported means that the technology used to build the site (HTML, CSS, Flash, Silverlight, Javascript etc) works with assistive technologies and browsers. Technologies which aren’t accessibility-supported in this way can be used, but can’t be used to achieve any of the success criteria. Note that this is the technology used to build the site: with earlier drafts people seemed to think this meant you could say it requires a specific browser, which is not the case.

Of course, the difficulty here is in establishing exactly which technologies are accessibility supported. I think it’s probably fair to assume that (X)HTML and CSS are broadly supported even though they aren’t perfectly supported in every case. With Javascript, you’ve got a much more complicated situation. Some parts of javascript are supported by almost every technology — so you’d be okay to use these — but some aren’t, and so you shouldn’t use them. The difficulty is in knowing which is which.

Note that Flash and Silverlight may be perfectly well accessibility supported (I don’t know); they don’t fail this accessibility-supported test simply because they require you to download a plugin; it’s all down to how well they communicate with assistive technologies.

Obviously the safe bet would be to use HTML and CSS, but we live in a world where a richer user experience is more and more expected than can be provided, with Web 2.0, AJAX and the content-rich features provided by the likes of Flash and Silverlight becoming increasingly expected. We’ve got to remember that we live in the real world and balance the requirement to create accessible content with an understanding that we can’t always support older and older browsers and/or browsers without required plugins.

Where you draw that particular line is up to you of course; but if you want to claim conformance with WCAG 2.0 you need to be sure that the technologies you are using are accessibility-supported.