WCAG Samurai Errata published

Just over a year ago, in his article To Hell with WCAG 2, Joe Clark announced that he had formed an invitation only group called the WCAG Samurai, which would publish errata for and extension to the Web Content Accessibility Guidelines 1.0, making the guidelines more usable on the modern Web. The errata would also be much more concise than the very bulky WCAG 2.0.

In the year that has passed since then, there hasn’t been a lot of talk about the WCAG Samurai, at least not any that I have noticed. But yesterday the WCAG Samurai Errata were published, along with two peer reviews by Gian Sampson-Wild and Alastair Campbell.

The WCAG Samurai Errata consist of two documents: an Introduction and an Errata listing.

The documents look pretty good to me, but there are some things I think could be rephrased or reworked a bit. The peer reviewers mention, I think, every issue I have with the current draft, and then some.

Some of the highlights:

  • Tables for layout are banned.
  • Frames are banned.
  • The noscript element is banned.
  • Valid markup is required.
  • Using correct semantics is required.
  • The accesskey and tabindex attributes are banned.

It’s good to see the WCAG Samurai Errata published. It will be interesting to see where it goes from here.

Posted on June 8, 2007 in Accessibility, Web Standards

Comments

  1. Interesting, thanks for the heads up.

    I’m very interested about that last point in fact. Tabindex is something that’s been causing a bit of anguish for me recently, it will be interesting finding out why it’s been banned.

  2. June 9, 2007 by Damian

    I agree with Gian’s assessment that this is a superior reference document for web professionals than either WCAG 1.0 or 2.0 and as such I think that the errata (once finalised) are something we should support.

    Let’s not “see where it goes”, let’s get behind it and make sure it gets somewhere.

  3. This may be the last piece of web accessibility work that Joe Clark will release; he announced at @media yesterday that there isn’t enough work for him to support himself financially, so he will be moving onto other areas.

  4. @Matt,

    I assume (and I haven’t asked, but anyway), there are two main reasons for dissuading people from using tabindex:

    1. The default tab order should be good anyway. Good separation of content and style should make this the default.
    2. tabindex causes issue because even when used well, it changes the order of the document between tabbing and other methods of navigating a document.

    For example, if you add tabindex to one item in a page, that then becomes the first item you tab to. But in most screen readers, you would ‘arrow’ through a document, going through in source order. If you then tab at any point, it’s quite confusing!

  5. I was a bit surprised at the section 10 guideline that seemed to say “don’t include a sitemap/table of contents unless it’s absolutely necessary”. I didn’t realise they were considered that harmful.

    Might just be me misunderstanding the language.

  6. What’s the problem with noscript? It’s banned in the introduction but not mentioned in the actual errata document.

    It seems like a good way to serve up alternative content to those without Javascript for whatever reason. For example, I use a noscript to hold a link to multimap for those who’s lack of JS means they can’t use an inline Google Map. I suppose I could use a div which is hidden by a bit of script instead, but it all seems a bit cumbersome when there’s already an element out there to do the job.

  7. June 10, 2007 by Stevie D

    I’m really intrigued by two suggestions in the Errata at the end:

    Do not provide a sitemap or table of contents unless the site cannot be understood or navigated without it.

    This seems unnecessarily restrictive, didactic and contrary to aims. Surely it would be better to say “Do provide a site map or table of contents if the site cannot be easily understood or navigated without”. How can having a sitemap, even if not really necessary, be harmful?

    Do not place distinguishing information at the beginning of headings, paragraphs, lists, etc. unless document semantics warrant it.

    Sorry, I just don’t understand what this one means…

  8. First, how is publishing an errata that useful? You can’t look at the errata by itself. You have to look at WCAG 1.0 + the Errata.

    If anything, it’s causing confusion. People are reading the errata without actually reading WCAG 1.0 like the introduction instructs.

    The errata would also be much more concise than the very bulky WCAG 2.0.

    Isn’t guidance what we wanted? WCAG 2.0 goes into a lot of detail on how to comply with the success criteria.

    If you want brevity conciseness, read and review the WCAG 2.0 Quick Reference. It just lists the success criteria and the appropriate techniques. There is also a little form where you can hide things that aren’t applicable.

    http://www.w3.org/WAI/WCAG20/quickref/

    As WCAG 2.0 enters the home stretch, how about we harness our collective energy to submit comments to the WCAG WG about WCAG 2.0, which most have said is leaps and bounds better then the last draft?

    http://accessites.org/site/2007/05/wcag2-woeful-to-wonderful-in-one-easy-draft/

  9. If one already knows about accessibility the WCAG Samurai Errata is a good checklist. I agree with most decisions. But it is lacking in many respects. And we have no warranty that criticism will be listened to.

    This is the only draft, and the document still reads like the work of one man (Guideline 11, bullet point 3, point 4: “I really mean this…”) and desperately needs to be rewritten into a more formal document.

    W3C is blamed for banning disabled user, etc, but the Errata does not cite any sources. What disabled people have contributed? How? (Oh, wait, it was a closed process, so everything must be fine!)

    If the W3C model is not open enough, establish something that is. An even more closed process is not the way to go!

    The decision not to develop this in the open and not have a clear formal dialogue with the development community, nor any formal support by any standard organization, will make this document extremely hard to cite as an authoritative reference in academic circles. That in turn will mean that professors will not teach from it - unless they have some real passion for the subject.

    It will be hard to require that students adapt their work or answer on exams according to what - in an academic setting - is nothing more than the personal opinions of a few (and mostly anonynmous!) industry professionals.

  10. June 11, 2007 by Roger Johansson (Author comment)

    Peter: Yeah, I read Joe’s post about that.

    Chris:

    What’s the problem with noscript?

    It doesn’t work very well, especially in situations where JavaScript is enabled but is filtered by security settings in a proxy or firewall.

    It also encourages degradation instead of progressive enhancement.

    pauldwait, Stevie D: Agreed on the wording for sitemaps. They should be allowed, just not required.

    Justin:

    You can’t look at the errata by itself. You have to look at WCAG 1.0 + the Errata.

    Right, and hopefully that’s what people will do.

    Lars: This is a draft, so please do submit your comments. I will.

  11. @Alistair

    “The default tab order should be good anyway. Good separation of content and style should make this the default.”

    I thought that too - however that’s not actually the case. Consider a document marked up as follows:

    skip links page header and intro main content main navigation sub navigation site information (i.e. footer)

    Without CSS, the tab flow will be perfectly logical. But with CSS the visual flow may be in a completely different order. When CSS is applied the tab focus becomes unpredictable and erratic, zipping all over the screen. That’s bad for usability - in fact a point that accessites.org penalised me for in a recent design. However, ‘correcting’ tab flow with tabindex then makes it wrong when CSS is deactivated or unavailable.

    Tabindex is useful, but I honestly think it ought to be a CSS property. As you say, natural flow is fine, but when CSS is repositioning elements, it’d be nice to change the tab-flow for the design itself to better align with the visual expectation of focus flow.

  12. @Matt

    Since tabindex is a HTML attribute, I believe that we should always speak about it as if there is no CSS styling applied.

    I agree with you, though, that if tabindex must be used it should be as a CSS property.

  13. There is little wrong with concept of NOSCRIPT in a modern browser. If it triggers a firewall then that’s a failing/enhancement of the third-party. As for keeping IFRAME oh dear.

    Interesting part about abbreviations it reads like it assumes you know how an assistive device will handle them in the first instance. Also there are some strange explanations in Guideline 12. Plus one or two other things that are badly worded or conflict with previous paragraphs in the documents but generally make sense.

  14. Unless I’m missing something, I can’t see any reference to access keys in the errata, but the post mentions they are banned… can someone clarify?

  15. @Paul M: I’ve only read the introduction so far, but it mentions this in the section titled ‘Priority 3 guidelines to ignore’:

    “Guideline 9.5: Don’t provide your own keyboard shortcuts. That is a job for a browser or adaptive technology.”

  16. I haven’t quite gotten through all of the WCAG Samuri Errata “manifesto” and have been thinking more about the process than the content.

    I am concerned about what those outside of the accessible web community will think about the proverbial “infighting” that has taken place as a result of the proposed revisions to WCAG.

    When I do training on Accessible Web Design, I often meet a fair amount of resistance and those who resist will use any reason to continue to resist. I can just hear them now, “whose guidelines should we be following….?” You get the point.

    I’ve blogged my comments here: http://www.jebswebs.net/blog/index.php?itemid=23

    ~j

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.