WCAG Samurai: Draft Errata Released

June 7, 2007

Topics: Accessibility, Web standards.

In May of 2006, after the release of WCAG (Web Content Accessibility Guidelines) 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 (HyperText Markup Language), 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!

Have something to contribute?

« Read my Comment Policy

16 Comments on “WCAG Samurai: Draft Errata Released”

  1. RE Breadcrumbs:


    /* Adds >> Double >> Arrows >> After >> Each >> Link */
    ul.arrows li:after {
    content: "020 020 020 0BB 020";

    Breadcrumb trail:


  2. I’ve added them. Still haven’t moved the site into a single CMS (Content Management System) (although I’m making plans to do it…), but they’re there.

    They aren’t, however, semantically organized in a list. I’ve actually decided that exposing them in a single line with separators is perfectly sufficient. I’m sure if anybody disagrees I’ll hear about it…

  3. Well, I’ll take that under advisement. It would help if I moved to operating the entire site under one CMS (Content Management System)…right now, breadcrumbs would be very clumsy.
    I can’t deny that the infrastructure of this site is getting a bit beyond it’s original expectations.

    As far as the nested/single list question, I’d absolutely say single list. Ben’s article talks about the value of semantics in a nested list versus the complexity of the code, and I’d have to say that the subtlety of the semantics to nesting lists doesn’t really seem to present great value.

  4. I firmly believe that they are seriously over-used

    Aha! That explains why i couldn’t find them on your site when looking for explanation. I’ll have to take this opportunity the, to say that I would have found them very useful on your site. I, for one, find breadcrumbs invaluable.

    I think we’ll go in between and hide both a heading “Document Tree” and an explanation of what the bread crumb is. Then, for visual users, add something like “Your location within the site:”

    The only question left is, should the links be presented as nested lists or a single list?

    Thanks for your feedback.

  5. That’s an interesting argument. I’m not sure I entirely agree, however. To me, the essential problem with Ben’s argument is that it’s based on the assumption that listed values are “hard to digest” without CSS (Cascading Style Sheets). This is something I don’t agree with — I see little challenge in understanding a list of links without the breadcrumb trail organization.

    For this, you can simply provide a label for the navigational device: “Navigation Trail”, “Breadcrumb Trail,” “Contextual Navigation” — whatever you believe to be the best label for your context, and you can conceal this from CSS-enabled browsers (if you choose).

    On the whole, I have my doubts about the overall value of breadcrumbs on most sites – I firmly believe that they are seriously over-used.

    We’ll keep on thinking about this, but there must be a solution which meets all categories!

    Hate to say this, but there might not be. This is the eternal problem with accessibility: sometimes, there isn’t a solution which is best for everybody. Instead, you end up needing to implement multiple solutions. You’ve really got a 5th category which should be in that list, as well – cognitive disabilities. This is where you may find yourself needing very clear explanatory language about what the breadcrumb navigation is, OR you may need to eliminate excess language in order to provide symbols which represent it. Depends on the audience.

    There’s almost always a trade-off of some sort.

  6. Unfortunately, I’ve hit a more solid argument (in my opinion) not to present breadcrumbs as a list (see http://sitesurgeon.co.uk/traditional-breadcrumbs.html), which has left us in the mess again!

    So, unless i’m wrong, we have a serious trade off between:

    1. Visually able users.
    2. Visually able users without images.
    3. Visually able users without css.
    4. Visually disabled users with screen readers

    We’ll keep on thinking about this, but there must be a solution which meets all categories!

  7. Hmmm…I don’t know that I have. That concept was just something that came into my head as I was writing! I can look around, though I’m pretty sure that the vast majority of breadcrumb paths use a character separator.

  8. Anywhere where you’ve seen this done?

  9. This is a case where I’d say using a background image is possibly the better choice — although it also is a case where you’re balancing options.

    If you set up your breadcrumb trail using a semantically separated element (such as a list, ordered or unordered), then the links are effectively separated from a screen reader perspective. You can then use background images on the links to give the visual appearance of a double chevron being used as a separator, without forcing these to be listened to by the screen reader user.

    In this case, you can potentially run into difficulties for users with images disabled, however: since the links may not have any clear visual separators other than the images. So, you need to consider using some additional separating characteristic, as well. One option is to actually use an image with a background color to match the overall background, then set a different background color on the link itself, behind the image. With images disabled, the links will be separated by this differentiation in color. It’s not a very strong choice, since it gives no sense of path, but at least it’s something.

  10. One point which i can’t get around is:

    “Do not add non-link, printable characters (surrounded by spaces or not) between adjacent links unless the semantics of the document naturally would include such characters.”

    Whilst i can understand how annoying it might/must be to hear a screen-reader say, “Home double-chevron Level 1 double chevron etc.”, what better way is there of doing breadcrumbs bearing in mind that a left-to-right double chevron is considered to be the most usable way of identifying the road between the current page and the home page?

  11. And I certainly agree that it shouldn’t be used “as a substitute for accessible scripting,” but that shouldn’t make it a banned element. Notification of JavaScript being disabled has a valid function, even if it won’t function in all environments.

    I think that use of the noscript element as a substitute for JavaScript content should be banned; but not the use of the element entirely.

  12. The problem with the noscript element is that it won’t work on all cases. A person in a company environment, for instance, may be sitting at a computer with a JavaScript enabled browser, but have script blocked by the LAN. That persons will not be able to get the JS content, nor will they get the noscript content.

  13. That’s the idea, at any rate. The argument for dropping them is that user agents should or do provide this facility: screen readers have header navigation, for example; keyboard navigation allows you to jump from link to link, etc.

    Skiplinks are intended to provide this ability when it doesn’t exist in the user agent. They aren’t the most effective system, to be honest, simply because you can’t easily scan to them. However, until an appropriate substitute exists in standard user agents, I’d still recommend them.

  14. After reading the errata and posting my own comments, I read yours and realized that I had missed the Skip Links item.

    I pondered it for a while and came to two conclusions.

    If you don’t have a Skip to Content link near the top of the page, then it almost suggests that the source order of the content would place the content at or near the top with navigation after it.

    But then, if the visitor got to your page and realized that although the topic was close to what they were looking for but not exactly right, and they decided to check out your site for a page that had exactly what they were looking for, then the user may benefit from having a Skip to Navigation link if the main body content was at the top of the source.

    I think of how I read pages (as a sighted person). My eyes generally skip to the content but if the content is close to what I am looking for but not quite right, I skip to the navigation bar too look there.

    The links may provide a means for screen reader users to skip around just like sighted persons do.

  15. Well, yes — naturally. I do intend to re-address once the final version is in. Thanks for stopping by!

  16. Keeping in mind that this isn’t the final version, I haven’t read the peer reviews yet, and all comments will be taken into account.