The WCAG 2.0: What a Whopper

Posted June 13th, 2006 by Jack Pickard

A twisted and winding path to Web Content Accessibility Guidelines, WCAG, 2.0 compliance When you pull together the WCAG 2.0 draft, understanding WCAG 2.0, techniques and about baselines document, and paste them together into Word with Arial size 10 font, they give a total of 518 pages, containing over 160,000 words and more than 11,000 paragraphs.

The sheer size of the documentation has been commented on before but it should be restated here: this is too large to be usable. Note that there have been some very good (and shorter) critiques of WCAG 2.0, such as those written by Joe Clark and Bruce Lawson. They will have inevitably covered some of the things I have, and they wrote theirs first. However, this is my opinion.

The Principles

The whole thing is set around four basic principles: that content must be perceivable, that controls must be operable, that content and controls must be understandable and that “content must be robust enough to work with current and future user agents.” I like the idea of these basic principles: it gives you a nice simple overview. Unfortunately for me, this fourth principle is where it starts to go wrong. If you’re asking people to “design using standards to ensure compatibility,” then ask for that. What it seems to be currently asking is that you’re being asked to be all things to all people, which is pretty much impossible. The details of the checkpoints (oops, sorry, “Success Criteria“) relating to this guideline refer to accessibility and to unambiguous content. This isn’t the same thing. But I’ll come back to that.

Without producing another 500 pages document, it’s not going to be possible to give a critique of everything, so I don’t intend to say “Success Criterion 1.1.1 is fine and understandable.” Although it is, by the way. WCAG 1.0 needs improving but on the whole it’s understandable and usable and I’m going to do WCAG 2.0 the service of asking you to assume the same thing, except where otherwise stated. Okay?


The first thing is the baselines. This allows you to set a technology level which must be supported by the user’s equipment. This allows you to say that providing you can handle Flash, PDFs, JavaScript, and Shockwave, my content complies with all the Level 2 success criteria. If you can’t handle these things, it’s your own fault, and I can still justifiably claim double-A conformance, as my baseline includes these. The other thing is that the baselines say: Note: “Baselines are not specified in terms of specific user agents.”

Unfortunately it’s easy to miss this small note, and because it uses the phrase “user agents” rather than the more commonly understood “browsers,” I expect it will be the first step back to they days of “this site is best viewed in Internet Explorer” and indeed this is what I first thought was the baseline was meant to allow meant until Gez Lemon privately and publicly expanded upon the concept of a baseline. You can also use technologies outside your specified baseline, provided you don’t rely on them.

As a slight side note — well, rant — can I tell all you “BrowseHappy” people out there that sometimes I want to use Internet Explorer, so I’d really appreciate it if you could stop telling me to use Firefox or Opera. I use all three as it happens, but the whole point is that it should be none of your damn business which one I’m using, and I don’t want to be told by you or anyone else to go and use a different browser, otherwise you’re just the techno-geek bastard spawn of those “best viewed in Internet Explorer” people. All right?

Conformance Levels and Claims

The conformance levels have changed slightly. For level single-A and double-A conformance, you must achieve all level 1 success criteria, or all level 1 and 2 success criteria respectively. For Triple-A conformance however, you must achieve all level 1 and 2 success criteria plus half of the applicable level 3 success criteria. I’m not sure whether this is a good or a bad thing. I think there’s a danger that this could cause confusion, thinking you only need to meet half the criteria to achieve any conformance level, but on the other hand Triple-A conformance under WCAG 1.0 was somewhat of a mythical beast, so to make it more achievable is probably a good thing. On the whole, I think I like this change but I wouldn’t necessarily expect everyone to agree.

Unfortunately, the WAI doesn’t appear to have generated any new conformance icons, which is a shame. On one hand, your accessibility Samurai doesn’t feel the need to wear badges, but on the other, a lot of smaller sites, agencies and the like would find this to be good marketing opportunity which may increase the chances of time and money being spent on accessibility. Seemingly, the reason that there are no badges is that now in order to claim conformance with a particular level, you’ve got to spend around five hours documenting it.

Yes, that’s right. If you want to make a conformance claim, you’ve got to list:

  • The data of your claim;
  • The version of the WCAG guidelines used;
  • A URL to those guidelines;
  • The conformance level satisfied;
  • The baseline technologies relied upon — although you might also want to mention those used but not relied on;
  • The scope of your claim (page, site, parts of site, etc.);

On top of that lot, it’s suggested that you might also want to include:

  • Any additional success criteria you’ve used;
  • A list of user agents you’ve tested with;
  • Your intended audience;
  • And which parts of your site were designed to conform with WCAG 1.0.

What’s the point of this? What benefit does documenting all this give to anyone?

A fellow “Team Access” member has already commented to me that they have no intention of fulfilling the bits of WCAG 2.0 where the regulation but not the user is served. They user will still either find your site accessible or they won’t, regardless of how much time you’ve spend documenting your conformance claim. A badge would allow you to show that you’re claiming that level of conformance, you’re claiming it while the badge is there, and you’re claiming it for the pages the badge is on (unless otherwise stated). Okay, maybe that doesn’t account for the baseline, but it’s certainly a starting point — and I’m sure there would be a few standard baselines in use.

The other thing with conformance claims is that we start coming across WCAG jargon. Like the fact that a conformance claim relates to web units or sets of web units. So what’s that? Well, the definition tells us that it is a collection of information, comprising of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier or URI. In that case, what’s wrong with calling it a web page? This is a meaningful term, that’s been used perfectly happily for a number of years and it’s understandable. Maybe it’s because some “web units” don’t look like pages. In which case, why not indicate that “web page” in this context also includes these, rather than using a new definition that will cause trouble for everyone?

In my opinion, the WCAG 2.0 documents are in very much in breach of the WCAG 1.0 Checkpoint 14.1, Priority 1, which states use the clearest and simplest language appropriate for a site’s content. Still, at least they don’t include a colophon on their home page…

Conformance claims should be as simple as “these pages meet this level of conformance criteria,” end of story. It’s not about asking people to explain what they’ve done to make their sites accessible, it’s about them just doing it.

The Meaty Guidelines

From the outset, the guidelines have a list of related issues, some of which are open and some of which are closed. I don’t have a great deal of experience with WCAG documentation so I don’t know if it’s common practice to continue to include this documentation once the status changes to “recommendation” but I’d hope not as this only provides another great area of potential confusion.

Nor am I going to go through every success criterion and guideline because I’ve already done it for an earlier draft, but I’ll pick out some of the ones that are causing me concern.

I must however say that the guidelines themselves tend to be very clear: “provide text alternatives for all non-text content,” “make all functionality operable via a keyboard interface,” “allow users to avoid content that could cause seizures due to photosensitivity” in a way that the actual success criteria themselves perhaps are not. Web units or authored components can be parsed unambiguously, and the relationships in the resulting data structure are also unambiguous.

Guideline 1.3 which seeks to ensure that information and structure can be separated from presentation seems to me that it should include WCAG 1.0 checkpoints 2.1 ensure that all information conveyed with color is also available without color, for example from context or markup and 3.3 use style sheets to control layout and presentation. Unfortunately because WCAG 2.0 has been designed to be technology-neutral, there’s no mention of style sheets. Providing the size or shape of the component is not required to operate it, and that you’re not conveying information by colour alone, you can meet guideline 1.3 ensure that information and structure can be separated from presentation by using font and align elements if you like. Yes, that’s right. You can use an element which was deprecated in HTML 4.01 nine years ago that ties the presentation of your page is into the page structure and content — there’s no success criterion telling you not to use deprecated features, and you can still pass all of the success criteria for the guideline which states “ensure that information and structure can be separated from presentation.” And this is a step forward?

I understand the drive to make WCAG 2.0 technology neutral but please, not if it’s going to cost us so much. What’s wrong with insisting that technologies must be used according to specification? There’s nothing technology specific about that.

Guideline 2.4, which is one of the more wordy with provide mechanisms to help users find content, orient themselves within it and navigate through it. contains some of the worst examples of jargon-loaded success criteria. “A mechanism is available to bypass blocks of content that are repeated on multiple web units.” Does this mean “provide a facility to skip past repeated headings and navigation sections?” Also know as “skip links?” Why I do believe it does. Okay, maybe my definition isn’t perfect surely could be made more readable than it currently is.

Or how about “more than one way is available to locate content within a set of web units where content is not the result of, or a step in, a process or task.” Did you read that and think Eh? What do you mean? You have to refer to the understanding WCAG 2.0 document to find out more. Fortunately, the instructions for how to meet the success criterion are more helpful, suggesting that you provide at least two of navigation links, tables of contents, site maps, search facilities or a list of links to all other web units. Hang on, what’s a web unit again? Oh yes, it’s “a collection of information, comprising of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier.”

What, all other web units? An entire Internet’s worth? Ah, no… if you read the techniques document as well, you are asked to provide a list of links to all the web units on the site. Rather than making me read the guidelines, and then the “understanding” document, and then the “techniques” document — particularly since only the first of these is part of the standard — why not simply tell me what you want me to do in the success criterion?

Titles, headings and labels need to be descriptive, but you can use your headings in any order you like. The mapping document hints otherwise, and refers to success criterion 1.3.1, but that only says “perceivable structures within the content can be programmatically determined” and all that asks is whether you can programmatically determine the heading level. You can programmatically determine the heading levels by the simple fact that you’ve used <h3> <h1*gt; <h2*gt; and the WCAG working group does not ask for them to be used “according to specification,” so as long as you are “using h1, h2, h3, h4. h5 and h6 for headings” you can presumably use them in any order you like.

One of the success criterion I have heard debated previously is the “dumbing down” [a] criterion — “where text requires reading ability more advanced than the lower secondary education level, supplemental content is available that does not require reading ability more advanced than the lower secondary educational level.” Apart from the obvious jibe that WCAG 2.0 seems to be failing this criterion, what does it actually mean? Lower secondary educational level is referred to as the level achieved by someone with between six to nine years of school. In the UK, that’s probably between 10 and 14. The argument here is that it may be more difficult for someone with dyslexia to understand difficult text, even if they are highly educated with specialized knowledge of the subject matter. That’s fine. However, setting this as a “lower secondary” would seem to suggest that you can’t use specific terminology that would have been learned by someone with this specialized knowledge.

However, what WCAG is asking for isn’t actually that bad. If you’ve got to provide text that can’t be understood by someone of lower secondary education, all you need to do is provide a more readable summary, provide visual illustrations that make it more understandable, or provide a spoken version of the text (presumably if you do this you’ll also need a sign language version).

It also mentions that you could consider “making the text easier to read” but to me this is simply asking you to “where text requires reading ability more advanced than the lower secondary education, make the text readable by someone with lower secondary reading ability,” which to my mind is a wonderfully circular argument.

If this is also being included to benefit users with dyslexia or similar cognitive disability, then it seems a nonsense that “using readable fonts,” which doesn’t even merit a link yet, is only going to be an advisory technique. Surely a readable font is essential to comply with the guideline “make it easy to distinguish foreground information from its background?” Should making sure your text is to some degree readable not be a level 1 criterion? Or are we assuming that if you can only understand nice crisp fonts in large size you’ll automatically have the technical know-how to set your browser up to ignore author style sheets? Unless of course the author has used font tags which are now perfectly okay again as we’ve seen, in which case you’ll need to delve a little deeper into your browser settings to make it readable.

And to meet criterion 4.2.4, you must meet all level 1 and 2 success criteria, regardless of whether or not they are technologies listed in your current baseline. I still can’t get my head around this one. This is not the same as saying “even if the user looking at your site doesn’t support all the technologies in your baseline, you must meet level 1 and 2;” instead it’s saying if you use a technology somewhere that is not listed in your baseline as required, you must still ensure that it is supported to level 2. How exactly are you going to use a technology that isn’t in your baseline? If it’s required to use your site, it must be in your baseline, and is obviously part of your standard conformance claim.

Alternatively, if you’re talking about a technology in your baseline that is “used but not relied upon” and you’re claiming Triple-A compliance, than for that technology, “the content would still meet WCAG 2.0 at the stated conformance level even if that technology is turned off or not supported,” which seems to be in direct contradiction with criterion 4.2.4. According to the baseline definition, if you use a technology, it forms an integral part of your conformance claim. According to 4.2.4, if it’s “used but not required” then you only need match it to level 2 if you’re trying to claim level 3 elsewhere. Well, which is it?

That Whole Darn Normative Thing

Some W3C documents are described as “normative.” This means that they form part of the standard.

Some W3C documents are described as non-normative. This means that they may be used to help you, but do not form part of the standard. They are therefore optional.

If you need to refer to a non-normative document to understand a success criterion, you can therefore choose to ignore that interpretation and instead substitute your own. The W3C have quite sensibly made the glossary normative (so you can’t redefine “lower secondary education” to suit yourself) but the documents that are necessary to understand a particular success criterion should all be normative.

This either means making the whole set of documents normative or moving everything necessary to understand the success criteria, baselines, conformance, etc., into the normative document. Otherwise there’s no point in looking at the “techniques” or “understanding WCAG 2.0″ documents, you might as well just do whatever you feel like!

One of my fellow Accessites colleagues tells me that he will employ the best from WCAG 1.0 and 2.0 regardless of what is described as normative, using those parts that he feels will best benefit the user, and discarding the parts he feels are of no benefit. To be honest, I believe that a lot of people who have a keen interest in accessibility do this anyway — we work from our knowledge of what we can do to make sites accessible and universal, rather than trying to fit to a particular set of guidelines — unless we’re seeking to claim some particular conformance. That doesn’t mean that those guidelines aren’t of great benefit however; not everyone has the time, inclination or ability to understand what is required for accessibility, and these people need to be catered for by the production of clear and concise checkpoints (oh, all right then, “Success Criteria“).


Ah. Global warming, mass extinctions, the threat of nuclear and biological terrorism, worries about rising sea levels, holes in the ozone layer and WCAG 2.0. In other words, progress.

That’s a bit unfair, however — there’s a lot of good stuff in the guidelines. And as I’ve said, there’s 500 pages of documentation and I’ve only pulled out a limited number of problems. So what am I objecting to, exactly?

  • The fact that WCAG 2.0 is less stringent than WCAG 1.0.
  • The fact that WCAG 2.0 is apparently self-contradictory.
  • The fact things no longer have to be used to any sort of standard, even though you can phrase this in a technologically-neutral way.
  • The fact that the documentation is vastly over-inflated.
  • The fact that the document is not in clear and concise language.
  • The fact that not everything required to understand the success criteria is defined as part of the standard.

Until all of these have been remedied, WCAG 2.0 is of little or no benefit. WCAG 2.0 is a great starting point for a document, and making it technology neutral is a great idea, but a half- (or even three-quarter) baked document is of no use to anyone, and it needs significant polishing before it will be ready for use. There has been a great deal of work that’s gone into WCAG 2.0, and I’m not saying it’s of no use; I’m simply saying it’s far from being ready. If WCAG 2.0 is given recommendation status before it is made ready, it will either be ignored, or misused and misinterpreted and then WCAG 2.0 will have been a step backwards, and I certainly don’t want to see that.

I would urge the Web Accessibility Initiative WAI to take their time over this; they’ve shown that they are prepared to listed and that’s a good thing. They have the basis of something that could be a very good document, but it’s not there yet. Don’t feel you can’t have further public revisions if necessary. The document can and should be saved, but it shouldn’t be used as it currently stands, otherwise I for one will be using the unofficial WCAG 1.0 guidelines as produced by Joe Clark and his secret Samurai.

Sorry. Comments are closed.

Note: This is the end of the usable page. The image(s) below are preloaded for performance only.