The WCAG Samurai Errata are now available

It took nearly two years, but two days ago on 26 February 2008, version 1.0 of the WCAG Samurai Errata for WCAG 1.0 were finally published. As stated in the Introduction, this version is also likely to be the final version.

A quick summary for anyone who is not familiar with the WCAG Samuari or their WCAG 1.0 errata: The WCAG Samurai consisted of a group of accessibility and standards-aware web developers brought together by Joe Clark in 2006. The group’s goal was to create a document that provides corrections and updates for the Web Content Accessibility Guidelines (WCAG) 1.0.

The reason to provide corrections is that since WCAG 1.0 was originally published by the W3C in 1999, both web browsers and assistive technologies have evolved. At the same time, accessibility-aware web developers have learned and invented a lot of techniques for building accessible websites. Developers have also learned that some of the techniques that were useful in the past are no longer needed or even cause problems for users.

The WCAG Samurai errata thus removes, rephrases, and adds information that makes WCAG 1.0 more applicable to today’s Web. You might also want to read Joe Clark’s WCAG Samurai errata released, where he talks a bit more about the errata and the development process used.

So do the WCAG Samurai Errata actually contain any improvements? Yes, definitely. I don’t agree one hundred percent with every word in the errata, but all in all I think they make a lot of sense and match what I strive for in my daily work.

Note that you can’t use the WCAG Samurai Errata as a standalone document. It should be used in combination with W3C’s WCAG 1.0.

Posted on February 28, 2008 in Accessibility

Comments

  1. I’m going to be moving forward with the WCAG 2.0. I have build a WCAG 2.0 site and it wasn’t that bad once the initial information overload was digested. I no longer think it’s as broken as I was first led to believe.

  2. I accept that the Samurai recommendations for use of PDF in accessible publishing is idealistic, but if you have ever tried semantically tagging a PDF file using Adobe Writer 8 then you might come to the conclusion that the existing authoring technology doesn’t allow you to achieve this in a practical way.

  3. February 28, 2008 by Bernardo Doré

    Nice! A genuine effort. I wish they’d give practical examples of the guidelines though.

  4. February 28, 2008 by Sarah Bourne

    I notice that the errata - like WCAG2 - allows client-side scripting. My understanding for its being banned before was because (most? some?) AT browsers did not have scripting support. I know that JAWS and WindowEyes now have scripting support, but are there other AT browsers we should be worried about?

    Most of the At users I personally know are blind, so they really can’t answer this question. I hope you don’t mind my asking here - I hope someday I will find someone who can answer…

  5. February 29, 2008 by Stevie D

    I notice that the errata - like WCAG2 - allows client-side scripting. My understanding for its being banned before was because (most? some?) AT browsers did not have scripting support. I know that JAWS and WindowEyes now have scripting support, but are there other AT browsers we should be worried about?

    There’s no rule against using client-side scripting - but it cannot be relied on for essential features. By all means enhance your website with (unobtrusive) Javascript, as long as all features can be accessed without it.

  6. Excellent! Just the sort of common-sense, no-nonsense stuff that we’ve come to expect from Joe. While a couple of the points are “arguable”, I think it’s much better to have a single, simple “stamped” standard like this than argue forever about the fringe cases.

    We’ll be following this over WCAG 1.0 from now on!

    @ Matt Williams #2:

    Agreed that Adobe Writer isn’t the best way to make PDF’s! Luckily as they point out, it is a “published” format, and there are many tools available for making PDF.

    What we often do is make well-structured HTML and then use PDFlib in PHP to make a tagged structured PDF of the same document - preferably on the fly. This fulfills both the requirement to “provide compliant HTML versions of such documents” and allows the document to be taken away as a single file, almost as some sort of “Portable Document” ;o)

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.