- From: Charles McCathieNevile <charles@w3.org>
- Date: Thu, 14 Sep 2000 05:29:49 -0400 (EDT)
- To: William Loughborough <love26@gorge.net>
- cc: w3c-wai-gl@w3.org
We have to balance against the need for easy introductions, the need for a sound technical specification. W3C Technical Reports such as the Guidelines have to meet a certain standard as specifications, and that means they need to make certain things (like whta is normative and what is informative) clear. This does not excuse us from writing in English that ordinary people can understand, but nor does it excuse people who are reading them from making the effort to understand what that stuff means and why it is there. If they are not interested in that thehn they should not be reading a specification, they should be reading an instructional text based on teh specification - like the zillions of books on how to write HTML that many poeple prefer to the HTML specification. We should use the clearest, simplest, most common language that accurately expresses what we are trying to say. If we simplify beyond that we lose content (that argument reminds me of something) and if we increase the amount of jargon and special definitions we lose comprehensibility. If people can't understand what is meant, they will have to make it up for themselves, and will do so differently from person to person. That leads to a loss of interoperability. That leads to a balancing act. But bear in mind that the WCAG is meant to be a definitive technical specification - we can't rely on another, more technical document to specify our requirements more exactly - WCAG is required to stand on its own. The Techniques are further explanation - more like the instructional material but anything that is required has to be in the specification itself. Charles McCN On Wed, 13 Sep 2000, William Loughborough wrote: A dear friend and gifted writer - also a skilled Web designer and accessibility specialist writes: "Obviously, I've only given it the most cursory of glances so far, but my first impression was that it's refreshingly lacking in the usual gobblydygook language of academia that's come to characterize most documentation of the W3C et al. I'm telling you, William, most people don't understand, much less use, words like "normative," and because they don't, they're put off by guidelines and recommendations that do. It seems to trigger some kind of defeatist attitude ("Yuck. I'm too dumb to do this because I don't even understand the instructions.") even before it sets off the lazy gene. ("Bleh. Too much work, this 'retrofitting.'") "Guideline Guide tickled me." Aside from the fact that she probably knows what I would like to hear in this regard, I think this is a very typical reaction to our document. Yes, we need a normative document but IMO it needs to be almost hidden away. More to the point is that if it can be presented in small bites, as called for, it might be less daunting. The way-too-extensive boiler plate at the beginning of each document is like the credits of a movie - one wonders at why they're being shown. Of course, I could be wrong. -- Love. ACCESSIBILITY IS RIGHT - NOT PRIVILEGE -- Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia September - November 2000: W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Thursday, 14 September 2000 05:29:50 UTC