Well, when I commented on the previous draft of Web Content Accessibility Guidelines (WCAG 2.0) for Accessites, it was definitely sitting closer to the ‘woeful’ category, and I was perfectly willing to tell them so. That was a year ago. They’ve since had ample time to work on it and improve matters. The question is, have they?
Judy Brewer, in an interview with the The Web Standards Project (WaSP), said:
…you’ll be seeing significant changes in the upcoming Working Draft. We want people to take a good look at this one when it comes out, and let us know what you think. — Judy Brewer in WaSP interview
Well, I have, and I will.
The two main criticisms that were leveled against the previous version were that the documentation was too wordy and was also bordering on incomprehensible. Taken as a whole, the documentation still comes to a sliver under 200,000 words, so it might still seem somewhat daunting.
However, to suggest that anyone has to read the whole documentation to use it is a fallacy: with WCAG 1.0 the checklist of checkpoints was referred to most, and then links from this to the supporting documents were followed if more information was needed.
The nearest equivalent to this for WCAG 2.0 is probably the WCAG 2.0 Quick Reference Document, which still comes to a rather hefty 14,700 words. Fortunately, however, this document is set up so that by changing the options at the top, you can rule out criteria that do not apply (e.g. if you don’t use multimedia, you can hide the features that relate to this).
Okay, it’s still some size, but unlike the WCAG 1.0 checkpoints, this also includes lists of common failures against the checkpoints, as well as techniques to ensure that the checkpoints — whoops, sorry, success criteria — have been passed. It’s therefore directly comparable to the WCAG 1.0 list of checkpoints with added cross-references.
This quick reference document will therefore serve as the primary document for my review, once I got past some of the other changes. Note that it’s not possible to cover everything in the document: I’ve tried to pick out a few things — hopefully representative — to give a ‘flavour’ of each section.
Principles, Techniques and Conformance
If you’ve read any of the documentation relating to WCAG 2.0 before, this section might not seem entirely new, but there are still some changes between this draft and the last one, so it’s probably worth reading anyway. If WCAG 2.0 is new to you, then this will serve to highlight some of the major differences…
First, the WCAG 2.0 are based upon 4 POUR (Perceivable, Operable, Understandable, Robust) principles:
- Content must be Perceivable
- Content must be Operable
- Content must be Understandable
- Content must be Robust
Within each of these principles, you have guidelines. Within each guideline, you have success criteria (née checkpoints). Unlike the WCAG 1.0 checkpoints, each of the WCAG 2.0 success criteria have been specifically designed to be testable.
Each guideline then has levels — the traditional A, AA and AAA — within which may exist various success criteria. It is possible for a higher level success criterion to be a stronger version of one found at a lower level, and equally it is possible that a particular guideline might not have success criteria at each level.
The success criteria that you have to use will depend upon the accessibility-supported technologies that you are using. HyperText Markup Language (HTML) and Cascading Style Sheets (CSS) count as accessibility-supported technologies: they are widely available and have accessibility support in many native user agents. Other technologies which are supported by widely available plug-ins would also qualify, but if you’re planning on producing your own encoding system accompanied by your own browser, don’t expect this to qualify.
Any information or functionality that is implemented in technologies that are not accessibility supported must also be available via technologies that are accessibility supported. — WCAG 2.0 (1)
It’s worth noting that this also allows for closed environments (such as corporate intranets) to rely on technologies which aren’t necessarily widely availably or accessibility-supported elsewhere provided that they are widely available and accessibility-supported within that closed environment.
There’s also an important distinction made between individual web content pages and pages used as part of a process:
Example: an online store has a series of pages that are used to select and purchase products. All pages in the series from start to finish (checkout) must conform in order to claim conformance for any page that is part of the sequence. — WCAG 2.0 (2)
In the previous draft of the WCAG 2.0 guidelines, it must be noted that in order to achieve the AAA (highest) level of conformance, you had to pass all of the success criteria at level A and AA, but only half of the relevant success criteria at level AAA. This has now changed to be more like WCAG 1.0: you must pass all of the conformance criteria to comply with that particular level.
Under WCAG 1.0, once you’d achieved conformance, you just had to stick a little icon on your page somewhere showing your conformance level (or more usually the conformance level you mistakenly believed you’d reached). WCAG 2.0 handles conformance claims very differently.
In order to make a conformance claim you must now specify:
- The date of the claim
- The guidelines, version and Uniform Resource Locator (URL)
- The conformance level satisfied
- A description of the scope of the claim (e.g. the whole site, which parts, any exclusions)
- The accessibility-supported technologies your claim relies upon
Note that ‘relies upon’ isn’t the same as ‘uses’. You can use whatever other technologies you like providing that your site is still accessible to a visitor at the same conformance level even if they don’t support technologies you use but don’t ‘rely upon’. Get it?
They then go on to suggest that you may also wish to list further things — other success criteria you’ve passed, other technologies you use, any additional steps you’ve taken to enhance accessibility and so on. As none of this is mandatory and is probably of very little benefit to any site visitor (see showing web accessibility statements the door — or not, as noted in this counterpoint), I wouldn’t put in anything that’s not mandatory.
For Web 2.0 technologies (i.e. those things with actual user interaction as opposed to “stuff with rounded corners”), there is an awareness that not all of the content is within the user’s control: comments on blog sites and similar are frequently outside the user’s control. The Working Group have arrived at the idea of a Partial Conformance Claim to cater for these:
A “statement of partial conformance” is made. A statement that the page does not conform, but could conform if certain parts were removed can be made. The form of that statement would be, “This page would conform to WCAG 2.0 at level X if the following parts from uncontrolled sources were removed.” — WCAG 2.0 (3)
These changes from WCAG 1.0 are very significant and show a marked improvement in this version of the document. This documentation is much clearer than previously (the previously incomprehensible “web units” being replaced by the common-sense “web pages”) and provided a very good shot at allowing WCAG 2.0 to function as a consistent, enforceable and technologically independent set of accessibility guidelines.
So, the quality and clarity of the documentation has improved — for which I’d like to nominate the Working Group for a well deserved pat on the back — but what about the Success Criteria themselves?