- From: Kynn Bartlett <kynn-edapta@idyllmtn.com>
- Date: Sat, 30 Sep 2000 18:57:04 -0700
- To: <gv@trace.wisc.edu>
- Cc: "GL - WAI Guidelines WG (E-mail)" <w3c-wai-gl@w3.org>
At 07:51 AM 9/30/2000 , Gregg Vanderheiden wrote: >the three issues that come to mind in reading it are >1) because you have omitted priorities, there are some things that are nice >but not critical that would block compliance. This should not be. it may >turn out that a site can't do one of them. Then you are blocked from >complying Gregg, can you give examples of these? I believe that if we are getting into "would be nice..." territory then we are in danger of hurting the credibility of our guidelines. My approach instead is to suggest that we make sure our guidelines and checkpoints really _are_ appropriate general rules, and if there are reasonable "short circuits" we can present those as minimal compliance options. For example, I illustrate this in proposed checkpoint 1.1.1 (Any), which says, in effect, if you don't have graphical or auditory content, you don't have to worry about this checkpoint. (Note that it does not automatically absolve you of other checkpoint responsibilities, though!) In order for this to work, each guideline must have at least one checkpoint which can give minimal satisfaction. To identify this as a bad idea, you would need to locate one or more checkpoints which cannot be "short circuited" or for which there is no appropriate "minimal compliance" technique which can be written. (And, of course, there is also the possibility that our existing checkpoints may not, in fact, be valid checkpoints under this system.) Can you point to any checkpoint which meets this criteria and supports your case that some "nice to do" checkpoints would block implementation? (This is not meant to say that I think Gregg is wrong -- this is part of the process of "testing" the strawman proposal. As the originator I have an obligation to offer at least a nominal defense of anything presented which hasn't been disproved yet, just for devil's advocacy's sake!) >2) You provide a clear definition of compliance (e.g. x+y+z=compliance) but >I don't always agree that you would NEED to do all of them - or that you >could not achieve the same result another way. Agreed. This is obviously a fault with the current approach; defining how exactly "partial solutions" work. However, I feel that we _will_ have to address this because: (1) Web designers and policy makers want to know, "What is the minimum that we need to do?" (2) Web designers and policy makers want to know, "When am I done? When have I done all that I reasonably need to do?" (3) Web designers and policy makers want to know from -us- what is important; a weakness of the current techniques document is that when a variety of options are given, they are left up to...nobody...to decide. (Asking the average reader of the guidelines to decide is highly inappropriate, as they are reading it _because_ they are not experts, in most cases.) Those are very important design considerations that we need to include in our next version of WCAG/Techniques. As we have decided upon technology-specific techniques as "children" of individual checkpoints, it will fall to _us_ to determine which techniques allow for checking of a checkpoint. Remember, everyone: "Checkpoints must be checkable." >3) Some of these are relative. Having all pages look and work the same is >NOT good design if taken too far. It is important that pages look >differently so that people don't get confused. Also, pages that have >different functions or for different audiences (on the same site) should be >organized differently and behave differently. Relative checkpoints and techniques are possible but need _very careful wording_ in order to be checkable. >This is interesting though and should generate some good discussion - and >maybe we can figure out how to pull the ideas out and avoid the problems. >This gets to feel (after awhile) like a Gordian knot. I agree. Someone hand me a sword. -- 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/ Accessibility Roundtable Web Broadcast http://kynn.com/+on24 What's on my bookshelf? http://kynn.com/books/
Received on Saturday, 30 September 2000 22:23:57 UTC