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
noscriptelement is banned. - Valid markup is required.
- Using correct semantics is required.
- The
accesskeyandtabindexattributes are banned.
It’s good to see the WCAG Samurai Errata published. It will be interesting to see where it goes from here.
- Previous post: HTML 5 and accessibility
- Next post: Keep HTML and CSS out of my inbox. Please.
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
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.
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.
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.
@Matt,
I assume (and I haven't asked, but anyway), there are two main reasons for dissuading people from using tabindex:
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!
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.
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.
I'm really intrigued by two suggestions in the Errata at the end:
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?
Sorry, I just don't understand what this one means...
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.
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/
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.
Peter: Yeah, I read Joe's post about that.
Chris:
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:
Right, and hopefully that's what people will do.
Lars: This is a draft, so please do submit your comments. I will.
@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.
@Matt
Since
tabindexis 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
tabindexmust be used it should be as a CSS property.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.
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?
@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."
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
Sorry, comments are closed for this post.