Re: clear & simple

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.

Charles McCathieNevile    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative            
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