Bruce Lawson's personal site

On the WCAG Samurai errata

So farewell then, Joe Clark.
“Approved persons may meet me”.
That was your catchphrase.

Joe is retiring from Web Accessibility, but his WCAG Samurai errata notes are a fitting epitaph. I think they’re an excellent summation of best-practice accessibility, and will serve as canonical guidance until WCAG 2 comes on stream (assuming it ends up fit for purpose). The whole document is a model of clarity; it bans and requires; it doesn’t wuss about ignoring PDF but sensibly bans useless PDFs that should be HTML; it makes the user agent responsible for accessibility as well as the author. Best of all, it requires semantic HTML, while simultaneously treating web authors like grown-ups.


I don’t necessarily agree with everything in there, but as the whole basis of the document is empowering web authors to make intelligent decisions, and as every project and client is different, there will of course be differences in the measure of “accessibility”.

Therefore, I’m going to be uncharacteristically modest and not ask that the Samurai amend their document because I do things differently sometimes. We all do, and that’s OK.

Here’s how my personal best-practice differs from that described in WCAG+Samurai:

  1. Skip links

    I use skip links on corporate sites and have had good feedback from blind users. Samurai is drafted in a manner that could be taken to ban them. “Skip links” is a technique that matches checkpoint 13.6: “Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. [Priority 3]”.

    Samurai bans conforming to Priority 3 checkpoints:

    No to Priority 3: Not only do you not have to comply with any Priority 3 guidelines, most of which are unworkable, you must not comply with them.

    You may dislike “skip links”; you may believe that the user agent should deal with them. But as they are not harmful, I see no reason to ban them.

  2. Validity

    The invalid <embed> is allowed by WCAG+Samurai – I agree with that. I also use tabindex="-1" to force IE to allow in-page navigation for keyboard users.

    Guideline 3 adds valid CSS to the mix:

    Any HTML or CSS inserted into a page by scripting or other methods must result in a valid page when actually rendered to the reader of the page.

    I know of no accessibility implications of invalid CSS, so don’t understand why CSS is included in this guideline.

  3. Alternate text for charts and diagrams

    This is a great section, that should sound a death knell for well-meaning, but worse-than-useless verbose descriptions of decorative stock photography. My only eyebrow raise is to the correction to Guideline 1.1:

    You can leave a text equivalent blank (e.g., null alt text, alt=””) if immediately-preceding or -following text has the same function as a text equivalent.

    I don’t think it needs to be as prescriptive as “immediately”.

  4. Layout tables

    Sad but true: because IE still doesn’t support the CSS display:table-cell, there are still some layouts that can’t be reliably delivered cross-browser without some highly convoluted and fragile CSS.

    I’ve never needed to code one, and probably never will, but if I am required to do so, I’ll use a layout table.

  5. ASCII art and animated GIFs

    I’e never used ASCII art, and I think animated GIFs are generally tacky (with a notable exception). But, if ASCII art can be skipped over, and if the GIF doesn’t flash dangerously, I don’t think they’re inherently inaccesible. (I know nothing about photosensitive epilepsy, though, so tell me if I’m wrong).

If I could offer one piece of advice to the WCAG Samurai before the final version is released, it would be to tone down some of the language employed. To corporates, the accusations that indentifiable people at the w3c are “bullies” and that “we’re more serious about multimedia than anyone else” reads like there are hidden agendas and axes to grind, which may affect people’s judgement of the advice in the errata and slow its uptake, which would be a great pity.

9 Responses to “ On the WCAG Samurai errata ”

Comment by Joe Clark

Well, we do have to honestly document why the Errata were written, Bruce. And *is* anybody more interested in multimedia accessibility?

Aaanyway, since you can use vendor-specific extensions in valid CSS, why should invalid CSS be permitted, even if there are no accessibility implications? (Valid HTML sometimes has none of those either.)

Comment by bruce

And *is* anybody more interested in multimedia accessibility?

– almost certainly not, Joe. But why say it?

why should invalid CSS be permitted, even if there are no accessibility implications?

– because they’re accessibility guidelines. Why require something that has no beneficial effect on accessibility?

Plus, useful things like word-wrap:break-word don’t validate, but they’re bloody useful. Why outlaw them?

Comment by AlastairC

I’ve come across a few instances of validity affecting accessibility. The last one was a malformed definition list, that rendered fine visibly, but was invisible to JAWs.

In some browsers invalid hacks can cause the rest of the style sheet to be ignored. Although most of these are caught visibly, I think it’s a useful check for people on alternative browsers.

For invalid CSS that is useful (for a particular browser, ahem, IE), I would stick it in a sheet from a conditional comment so only those with that browser have to download it…

Comment by Bruce

Cheers Alistair: the malformed definition list: do you mean the html was invalid? (I’m not understanding how this example shows that valid css is an accessibility requirement).

You say “In some browsers invalid hacks can cause the rest of the style sheet to be ignored.” – do you have a reference to which browsers and which hacks these are? (And are disastrous bugs like a combination of characters causing rendering failure/ browser crash accessibility problems, except in the least-technical sense of the word?)

The argument against requiring people to use conditional comments is that they themselves are against specification (although they validate fine, and the argument isn’t a particularly compelling one to me).

Comment by ppk

“inherent inaccessibility in this use of the noscript element.”

The problem with noscript is old JavaScript browsers. Take Netscape 4 – it doesn’t support modern W3C DOM JavaScripts, but as soon as you use the noscript tag you ask it “Do you support JavaScript at all?”, and it’ll answer Yes, since by its own lights it supports JavaScript.

So the few remaining Netscape 4 users will not get the scripted interface, but neither will they get the noscript interface. That makes the site inaccessible.

True, this group of users is not very large, but it’s often relatively easy to avoid use of the noscript tag.

I’m not sure if this is what the WCAG Samurai meant, but it’s the reason I don’t use noscript any more.

Comment by Ian Lloyd

Bruce, to add to what PPK said about older browsers, there’s another scenario:

* Browser is JS capable
* Firewall strips some (or all) external JavaScript

Hence, the content isn’t displayed and the JS does not get triggered.

Comment by bruce

Convincing arguments, ppk and Lloydi. Amended my post to that effect.

(I had said:)

<noscript>

Banning noscript is absolutely correct from a philosophical standpoint. However, it makes life much harder for me, as an author who’s not a scripter. As Chris Hunt writes,

“I use a noscript to hold a link to multimap for those whose 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.”

I do exactly the same and don’t know how to do it with script alone. I’ll continue to do so; I don’t support compromising accessibility to make the web author’s life easier, but I see no inherent inaccessibility in this use of the element.

Comment by Joe Clark

Anyone with enough knowledge to argue about these things (a) isn’t the market for the Samurai Errata and (b) could write their own. It’s one group’s opinion, not yours.

Comment by bruce

Joe, chill out.

As I said above, “I’m going to be uncharacteristically modest and not ask that the Samurai amend their document because I do things differently sometimes. We all do, and that’s OK … Here’s how my personal best-practice differs from that described in WCAG+Samurai”.

This isn’t gladiators, my/ our criticism is constructive.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.