WCAG 2.0 - A Failure In The Making?
Joe Clark recenty published a blistering attack on the the much awaited Web Content Accessibility Guidelines (WCAG) 2.0 and not, it seems, without very good reason.
Having spent the best part of 5 years developing the draft, it would appear that all that the Web Accessibility Initiative (WAI) committee have managed is to produce over 400 pages of documentation (159,800 words, according to Joe) that, far from improving the situation for accessible web designers, seems to have created an environment ripe for confusion. To add insult to injury, although the committee took approximately 1825 days to put this final draft together, they decided to give you and I only 34 days to comment. The final draft was published on 27 April 2006 and you have until 31st May 2006 to comment on it.
Whilst I can appreciate that an overly extended comment period would have done nothing to speed the inaugration of WCAG 2.0, 34 days seems to be rather mean sprited - especially given the potential that this document could have worldwide. Even the methods available for submitting comments do not lend themselves to effective discussion. You can opt to either submit your comments via an Excel spreadsheet (uh!), an HTML table (ok - a table is a fairly standard method of collating comments), a text form or via an online comment form which will automatically submit your comments to public-comments-wcag20@w3.org. If you opt for the latter route, it would be standard practice (one would assume) to first check the public mailing list archives to see if your point had already been raised.
Good luck! This isn’t exactly the kind of archive one can browse by sub-topic. Given the resources available to WCAG, I find it suprising that they couldn’t have come up with a better online archiving/publication method if they really wanted to elicit feedback. Or are they not interested in hearing from disabled users? For that matter, how many members of the working party have disabilities? Was feedback elicited from pan-disability user groups at any of the earlier draft stages? Just how accessible is the WCAG working group? Not very, according to Joe.
However, onto the draft itself.
I’d like to be able to comment on various points within the draft at some length. However, I have a problem. The language of the document is extremely dense and subject to a number of possible interpretations. Concepts such as “web units” are introduced and references are made to whether content can be “programmatically determined”. Apparently this latter term means that the author is responsible for ensuring that the content is delivered in such a way that software can access it. Why didn’t they just say that? Or better still, use the opportunity to make the point that, although the end-communication occurs between humans, the intermediate communication is between machines, so make sure that your content is machine interpretable?
The draft also refers to “baselines”. I had to turn to a secondary reference document to find out what a “baseline” was but this turns out to be a set of technologies that an author assumes are supported and turned on in accessible user agents.
OK - I’m following it so far (although I find the lack of plain simple language worrying) but then, the reference document states:
“A baseline may be set by a government body, client, organization, author, or combination of these.”
Uh?
So individual companies, or even authors, can decide what they consider to be baseline technologies and can claim WCAG 2.0 compliance if:
“a user agent can support the technologies listed in the baseline”
What user agent(s)?
So I can create a complete site in MuMble, build a user agent that can support MuMble and then claim WCAG 2.0 compliance - even though no one else can access the site at all?
Yes - that is blatantly facetious but it does hopefully illustrate that it is going to be extremely difficult to develop an internationally accessible site under WCAG 2.0 if baselines can be locally determined. If you want a reasonable song, it pays to ensure that everyone is using the same songsheet for a start.
I’m now about 1/8th of the way through the document. I haven’t, as yet, gone beyond “The Four Principles of Accessibility”. I’m not even close to reading the actual guidelines yet and I’m having problems understanding this document. And I’m well used to working with accessibility guideline documents. What hope do less experienced developers have?
Since I have no desire to totally bore anyone and given that Joe Clarke has done a far better job than I could do (and this is not someone I always agree with), I’ll just give you one small taste of the guidelines themselves.
Level 1 Guideline 1.2
Provide synchronized alternatives for multimedia
“1.2.2 Audio descriptions of video, or a full multimedia text alternative including any interaction, are provided for prerecorded multimedia.”
And what’s a “full multimedia text alternative including any interaction”? Apparently it’s a:
“document including correctly sequenced descriptions of all visual settings, actions, and non-speech sounds combined with descriptive transcripts of all dialogue and a means of achieving any outcomes that are achieved using interaction during the multimedia”
(full multimedia definition)
and “multimedia” is defined as:
“audio or video synchronized with another type of media and/or with time-based interactive components”
(multimedia definition)
So to summarise, in order to conform with Guideline 1.2, you need to provide a synchronised (text) alternative for all multimedia that, itself, makes use of multimedia by means of something called “multimedia text”.
Anyone know what “multimedia text” is? And won’t the “multimedia text” need an alternative - precisely because it’s “multimedia”? Only I’m getting a headache and I’m only on the second guideline!
I currently have no idea who this document was written for. Perhaps it was written to satisfy stakeholders within the Working Group as it certainly doesn’t seem to be useful to those of us who are actually “out there” trying to develop accessible web sites and encouraging others to do the same. Some years ago, on one of the mailing lists I inhabit, a comment was made that W3C’s apparent willingness to progress to an XHTML 2 specification, when XHTML 1.0 (let alone XHTML 1.1) was still poorly supported, suggested that the working party responsible didn’t live in the Real World. I can only suppose this is a state of mind that is endemic amongst other W3C working groups - especially the one responsible for this document. In it’s present state, WCAG 2.0 is likely to do more damage than good.
As a direct result, Joe has announced WCAG Samurai which will attempt to address the situation by concentrating on issues within WCAG 1.0 in an effort to provide a usable, practical, document. At this point, WCAG Samurai seems to be the only light in an extremely dark tunnel and I, for one, will be paying close attention to it.
I was at a SUPA meeting last night which covered WCAG 2.0. And one interesting area that was mentioned was ‘baselines’. From what I gather, when a ‘government body, client, organization, author, or combination of these’ set a baseline, the are simply creating a string which defines the technologies they expect people to use. At the moment this string is not machine-readable, so what atually happens or who actually uses this string is still a little confusing to me. But, the idea that this string may be accessible by user agents, almost like a DOCTYPE, sounds interesting. Perhaps we’ll soon be looking at messages delivered from user agents advising us that a certain website needs a certain technology?
If user agents ever do reach the point of ‘reading’ what a given site needs in the way of technology, how does this help the user? Especially if they don’t have access to technology X?
Looking at ‘baselines’ from this angle, my concern would be that we would have simply taken all of the “This site requires Flash 8″ (and similar) messages off the screens only to place them in machine-readable messages. It doesn’t solve the problem - just shifts responsibility of informing the user from the site to the user agent. Added to which, site owners, having been lured into feeling that they have Done The Right Thing by WCAG 2.0 in providing a baseline, might be even less inclined to tackle the root issue i.e. opening their site up to the widest possible audience.
Of course, the ‘baselines’ will need to be set by a responsible web site owner. It shouldn’t be any different to the way things are presently done (if they are done properly that is). If the site is intended for the widest possible audience and the site uses Flash, then obviously the site owner needs to provide an alternative.
Spot on Mel. The single greatest worry for me is that WCAG 2.0 will alienate those developers who are just starting to learn about accessibility. WCAG 1 isn’t perfect, but at least it’s straightforward. Anyone can understand the concepts of guidelines, techniques and conformance levels, i.e. the important bits. WCAG 2.0 on the other hand seems to do its darnedest to hide the important bits. If I was starting out now there is absolutely no way I’d wade through the new documents. No doubt some kind soul will produce a plain-english, simple-person’s guide to it in due course, but it will too late for many.
The problem when producing a plain-english guide will be how some parts of WCAG 2.0 should be interpreted. I think we’re going to find that different people will apply quite different interpretations to some checkpoints. There’s nothing new in that. Developers have been arguing over some points within WCAG 1.0 for years and, although some of that discussion is healthy and probably lends itself to a deeper understanding of the principles behind the guidelines, I had hoped that WCAG 2.0 would clarify some issues - not make things worse.
I liked reading your blog !