- From: Kynn Bartlett <kynn-edapta@idyllmtn.com>
- Date: Mon, 14 Aug 2000 19:54:30 -0700
- To: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Cc: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Here's my take. (I'm still catching up with the archives, so apologies if I go over ground that's already been gone over before.) _The_ most important thing that the Guidelines can ever provide are a set of checkpoints which, if followed by a responsible web designer, will result in increased accessibility for all users, particularly those with special needs. That's our mission as _I_ see it, and we need to be careful to _not_ lose track of it. Broad principles are very good and very useful. They help to give context to the checkboxes and explain why exactly things are done, in addition to heightening awareness and providing web developers with the ability to make their own judgment if they are encountering new technologies or situations not covered by WCAG. However... I don't think they're necessary at all in a document that primarily deals with _how to do the right thing_. And I think that HTDTRT (acronym for "how to do the right thing") document is of immense value as a formalized, definitive standard for the web, and the list of vague principles is of questionable value to what we are trying to accomplish, by comparison. I propose that we focus on the HTDTRT document, but that we also create a Principles of Web Accessibility document that is published as a W3C note and which is referred to extensively in our HTDTRT document. A way to visualize this -- if we look at the original strata of the WCAG, the "techniques" were on the bottom and got pushed out to a non-normative W3C Note. I simply propose that we do that with the top of the strata as well, putting the broad principles into another Note, which is considered good and valuable, and which can explain the HTDTRT checkpoints, but which is not part of that document itself. Then we get to the HTDTRT checkpoints. I believe that we need to group related checkpoints together under "strategies" as has been suggested, and I furthermore believe that checkpoints _must_ be technology-based. For each group of strategies there should be a set of HTML checkpoints, a set of CSS checkpoints, a set of XML checkpoints, a set of SVG checkpoints, and so on. If this means that we will need to publish an addition to the WCAG whenever a new technology is released, then so be it -- it may mean that we need to define WCAG itself in modules a la modular XHTML! Checkpoints must be specific and they must be checkable. They must be understandable with reference to the WCAG Principles document and the WCAG Examples document. (Oh, that's right, we should drop the term "Techniques" for that document because that's not the plainest, most straightforward term for what it does. WCAG Examples nee Techniques should be a set of sample code and example which show how to meet each checkpoint.) There's my pie-in-the-sky description of how I'd restructure WCAG to make it easier to understand. What do you think? -- Kynn Bartlett <kynn@idyllmtn.com> http://kynn.com/ Director of Accessibility, Edapta http://www.edapta.com/ Chief Technologist, Idyll Mountain Internet http://www.idyllmtn.com/ AWARE Center Director http://www.awarecenter.org/ Vote for Liz for N. Am. ICANN Nominee! http://kynn.com/+icann
Received on Monday, 14 August 2000 23:05:14 UTC