RE: A PROPOSAL TO SPLIT THE WCAG IN THREE. Please read this. I'm serious.

Gregg Vanderheiden wrote:
> Were you suggesting breaking the guidelines into 3 documents? Or just
> regrouping along different titles?

I am suggesting both (well, either). I see benefits to a complete split,
primarily that the Accessibility (device-independence) guidelines can go out
almost immediately, I suspect, and that the Comprehension guidelines can be
given the attention they deserve. Even if split now, the final three sets
could be recombined later. Maybe we could put out "device-independence" and
navigation guidelines now. Then we could take time to study, expand, and
perfect the comprehension guidelines. Finally, we could reintegrate them and
release the whole as a single set of guidelines.

But if the problems with this approach prove insurmountable, I'd consider a
revision of the current WCAG 2 structure. In this instance, I'm not sure
whether we should stick with the current division (presentation |
interaction | comprehension | technology), rewrite to (accessibility |
navigation | comprehensibility), or consider a third option: (presentation |
structure | content).

HERE IS THE KEY POINT:

It seems to me that there is a lot of controversy in this WG over
conflicting/overlapping checkpoints. We can't seem to agree on what goes
where. What that suggests to me is that we haven't sliced the guidelines up
quite right. We are cutting against the grain. I can't help but think that
if we can just find the right places to cut, the conflicts will vanish (or
at least become clear enough for us to reach a compromise). I am trying to
bring fresh eyes to the problem and to suggest (or stimulate ideas for)
different ways to view the guidelines. The two suggestions I make above
(A|N|C and P|S|C) are the best I can come up with off-hand, but there may be
others.

To me, the biggest difficulties we face are in making content
comprehensible. As I mentioned earlier, checkpoint 3.3 actually says
nothing, it just restates the goal: make content comprehensible. It says
nothing about how to accomplish this. We need to provide methods for making
content comprehensible. What do we mean by "clear"? What do we mean by
"simple"? How are these accomplished in writing? Shouldn't non-verbal
communication be clear and simple, too? Why isn't there a checkpoint that
says "Draw as clearly and simply as is appropriate to the content"? What
does "appropriate" mean? How do we know when we've achieved appropriate?

In a sense, we won't know whether we've got the checkpoint right until we've
understood the techniques required to implement the checkpoint. I think
refocusing on content rather than mixing content and code under the heading
"comprehensibility" might be an even better approach.

(BTW, now that I understand that this "release" will not prevent a guideline
split down the road, I see no need to delay release. I'd like to continue
this discussion, however.)

Chas. Munat

P.S. On names:

I think the best bet (if Charles will yield) is for me to be Chas. and
Charles to be, well, Charles (or Chaals, which I can never be, I think). So:

Charles Munat = Chas. or Chaz
Charles McCathieNeville = Charles or Chaals

Does Chaals agree?

Received on Monday, 20 August 2001 15:15:17 UTC