In May of 2006, after the release of WCAG 2 for public comments, Joe Clark published an article in A List Apart in which he damned the new guidelines to hell. At the same time, he announced the formation of an independent group to review WCAG 1 and author a set of errata (and extensions) to that document. The WCAG Samurai have now released their errata document for public review.

They have also invited reviews from a couple of prominent authors and developers in the web accessibility community, Alastair Campbell and Gian Sampson-Wild. Neither of these reviewers are members of the WCAG Samurai, and have each provided exemplary and honest reviews of the document.

Gian’s review, in particular, contains an incredibly quantity of detail and insight into the WCAG Samurai’s information. Regardless, both documents and the WCAG Samurai errata itself are well worth reading.

In general, the errata provide significant clarity of purpose in accomplishing web accessibility, by making use of very clear language: the document doesn’t hesitate to explicitly ban or require specific choices. It also makes very clear allowance for the use of common sense. On many issues, it specifically requires the developer to make a decision on an accessibility issue (regarding text equivalents or semantic HTML, for example). It allows for the fact that a perfect text equivalent is subjective and that semantic choices are not perfect in HTML: decisions need to be made.

The WCAG Samurai errata are NOT a document for a beginner. They require a strong awareness of the WCAG guidelines in order to make sense. The errata document does not provide direct linked reference to WCAG 1, nor does it provide the text of WCAG 1.

It’s important to recognize, and the document does an excellent job of conveying this, that the errata are JUST errata. They are intended to make corrections to the content of WCAG 1. As such, they do not address issues which are not addressed adequately in WCAG 1. As such, cognitive disabilities remain largely un-addressed.

My first impression: this is an excellent supplement to WCAG 1. When creating a standard HTML/CSS based website, these errata should absolutely be addressed and considered. I don’t agree 100% with every decision made: but there is absolutely no question that a project following these revisions to WCAG 1 will posses a superior level of accessibility.

WCAG Errata I Don’t Agree With

It requires that the <noscript> element never be used. Although I absolutely agree that the noscript element should not be used as a substitute for accessible scripting, I do believe that there is sometimes a value to providing notification to a user with JavaScript disabled that there is a scripted element missing or disabled due to their preferences.

I feel that the WCAG Samurai places a great deal of faith in the user agent. There are many guidelines where the errata state that a task is not the responsibility of the developer and should be ignored. Although I agree that this is the case, I’m also concerned about the practicality of this perspective. It is an unquestionable fact that many user agents do not provide sufficient accessibility, and I don’t think that this fact should be entirely ignored. It’s a slippery-slope problem, however: supporting technology which itself fails to provide the accessibility tools it should be responsible for can only go so far. I don’t want to be looking at continuing the position where all device compatibility is the responsibility of the developer. I’m not sure this is precisely something that I don’t agree with; I just would be inclined towards more cautionary language in context.

The elimination of Checkpoint 13.5, which requires navigation bars to highlight and give access to navigation mechanisms is perhaps a bit too severe. The fact that not all sites will require a navigation bar doesn’t seem like it should equate to ignoring the checkpoint entirely. The checkpoint should remain relevant, but allow for developer judgement as to whether it is necessary for their context.

I question the elimination of consistency in Checkpoint 14.3. I see no value whatsoever in eliminating this recommendation. Granted, the elimination of a requirement is not equivalent to recommending the opposite; but I feel that a certain degree of consistency should be a requirement.

I feel that the “skiplinks” requirement of Checkpoint 13.6 is still a valid expectation. Yes, it’s not an ideal solution. Yes, it’s not really needed by many disabled populations. However, it is very helpful: perhaps it’s moving to far towards usability and away from accessibility. Nonetheless, I’d prefer to see it remain. (Albeit rephrased for clarity, as the WCAG Samurai have done so well elsewhere!)

There’s probably more that I don’t entirely agree with, but on the whole I find the document to be a welcome breath of clarity. This is, of course, just the draft document: there will undoubtedly be changes. I look forward to seeing them!