- From: Charles F. Munat <chas@munat.com>
- Date: Fri, 17 Aug 2001 15:12:44 -0700
- To: "WAI Guidelines WG" <w3c-wai-gl@w3.org>
Here are a few thoughts, expressed as simply and clearly as I am able to express them: 1. There is no right to accessibility per se. There is a right to participate in society. There is a right to have a say in those things that affect us. Accessibility is simply a means to these ends. I cannot participate if I am locked out. Let's not forget what we are really after: equal participation. 2. There are no people with disabilities. There are only people, all of whom have some degree of ability/disability, usually varying widely throughout life and across the population. We are not concerned here with promoting the rights of people with disabilities. We are concerned with promoting the rights of people WITHOUT REGARD TO DISABILITY. There is a difference. 3. Equal participation is not the same thing as full participation by all. There was a concert in town last week that I really wanted to see, but I had other obligations. Should the concert promoters have postponed the concert until I was available? Full participation is neither possible nor desirable. One way to increase participation would be to create a monoculture in which everyone spoke the same language (with the same degree of fluency), had the same abilities, did the same jobs, wore the same clothes, etc. Is this desirable? I think not. 4. "Accessibility" is the ability to get access to information. Accessibility has nothing particularly to do with people with disabilities, except that they have been denied access more often than others. But that is a political issue, not a technical issue. (Personally, I'd like to pull the politics out of the guidelines, which is one reason I resist those phrases that smack of advocacy to me.) 5. "Comprehensibility" is the ability to comprehend that information once it has been accessed. 6. The WCAG seems to be changing from a document concerned with accessibility, to one that attempts to address both accessibility and comprehensibility. 7. Accessibility is largely under the control of the Web site developer. Comprehensibility is not. I can write my code a certain way and be reasonably sure that it is accessible to everyone. I can also test this using different browsers, operating systems, etc. But the best I can do with regard to comprehensibility is test my content on sample groups of people. To really ensure that material is comprehensible, I have to interact with the user, just as a teacher lecturing to a group of students cannot be sure that they have understood the material until test time (and even then, maybe not). 8. Making sites accessible -- in general -- eliminates duplication. By coding my pages properly, I can have one source of content which works well on many browsers (instead of the old method of making one version for Netscape, one for IE, and to heck with the rest). Yes, I can use server-side (or client-side) transformation to present multiple views of that content, but it's still only ONE SET OF CONTENT. 9. Making sites comprehensible -- at least as far as WCAG is concerned -- seems to consist of making multiple versions of content. Call it the "shotgun" approach to comprehensibility. Worse, the skills required to "ensure" comprehensibility of content go beyond those of the average Web site developer. Creating multiple versions also involves significantly more time, effort, and money. The effect of this may be to DISCOURAGE participation -- to lock out all but those entities with deep pockets. If forced to comply, commercial sites will. Non-commercial sites will simply go out of business. This group needs to think hard about the possible consequences of demanding total comprehensibility before we head too far down that path. Equal participation demands that the needs of content providers be considered, too. 10. We are making guidelines, not laws. We cannot enforce compliance, NOR WOULD THAT BE DESIRABLE. The whole point of guidelines is that people can take 'em or leave 'em. Partial conformity is GOOD. The idea here is to encourage people to make sites accessible (and comprehensible) UNLESS there are compelling reasons to do otherwise. And there WILL BE compelling reasons to do otherwise. Some sites -- namely, government and commercial sites -- MUST be made accessible and as comprehensible as is reasonably possible, but that is not the task of our guidelines. Such regulation is properly performed by governments (with the consent of the governed, one would hope). Just as Section 508 implemented parts (but not all) of WCAG 1.0, we can look to government to refine accessibility regulations to address some (but not all) of the concerns expressed in WCAG 2.0. For this reason, I am satisfied that the current document does a good job of promoting accessibility/comprehensibility. This group has done a remarkable job of finding a difficult balance between not going far enough and going too far. 11. Partial compliance is better than no compliance. We should beware of making users think that the Guidelines are an all or nothing proposition. Instead, we should encourage developers to comply with as many checkpoints as is reasonably possible. We should acknowledge that time, money, or ability constraints may make full compliance unreasonable. There is a resistance to this in this group because of a very reasonable fear that many sites will then abuse the guidelines to give themselves an appearance of compliance without really adhering to their spirit. THERE IS NO WAY TO AVOID THIS. Give up. If you want to enforce compliance, go to the government and petition for regulations. That is the ONLY way, short of massive protest, that you will get many organizations to comply. THEY DON'T CARE ABOUT ACCESSIBILITY. On the other hand, if we admit that our guidelines are just that: guidelines, and we encourage full compliance but accept partial compliance as a reasonable compromise, then we will most likely achieve a much higher level of compliance than we will by insisting upon full compliance. Accessibility is not an either/or proposition. 12. The guidelines are about ACHIEVING accessibility, not about PROMOTING accessibility. Mixing explanation with advocacy only muddles the guidelines. Much of the difficulty this group has had with expressing ideas clearly stems from muddled motives, IMO. Stop telling people WHY they should make their sites accessible and focus on telling them HOW. This is not to say that promoting accessibility is wrong, nor that we should not include the benefits of taking an action as part of our explanation. But listing benefits and SELLING them are two different things. There is a place and a time for promotion, and it is NOT in the guidelines. If we mix the two, we run the risk of alienating users who just want to make their sites reasonably accessible without hearing a sales pitch. Worse, we come across as preachers or as teachers. I'm all for preaching the gospel of accessibility, but I hope we can all agree that the guidelines are not the place for preaching. Teaching is a bit more slippery. What could be wrong with teaching? Well, in my experience the quickest way to alienate a Web site owner/designer is to offer to teach her something. These people view themselves as "experts." To become students again, they must step down into a subordinate role. That is uncomfortable for them. THIS DOES NOT MEAN THAT THEY DON'T WANT TO LEARN, ONLY THAT THEY DON'T WANT TO BE TAUGHT. Anyone who has worked with training for adults understands this distinction. There is a difference between training and teaching. Kids are taught. Adults are trained. Teaching implies a vertical relationship with teacher on top and student below. Training implies a lateral transmission, with trainer and trainee equal. When we start asking questions that sound like they're intended for children, we are "teaching." I guarantee you that many adults will find this style offensive. When we present information clearly and simply and let the reader make his own decisions, we're "training." No loss of status is involved. I can't stress this strongly enough. Frankly, I don't believe in teaching at all, not even for children. I prefer to speak to children with the same tone and level of attention I use for adults. I may speak simply, but I don't "dumb it down" for them. I find that children respond very well to this. My three-year-old niece has been raised in this environment, and she has no trouble at all identifying the patronizing tone so often used in "teaching." When approached by an adult in this manner, she immediately asserts herself: "Don't talk to me like that! I don't like it!" And well she shouldn't. Some of the above are facts, some are opinions. I don't expect everyone to agree with me, but I hope that by elucidating these ideas, I've stimulated thought about our task and our motives. With this in mind, can we reread our document with a critical eye and, as Faulkner said, "Kill all [our] darlings"? Let's run v.2 through a sieve and sift out anything that doesn't directly address the HOW of making a site accessible. While we're at it, let's examine our tone and make sure that it is appropriate for our audience. Let us assume that people will read our document because they WANT to make their sites accessible. Let us NOT assume that our readers have to be wrestled into conformity with sticks and carrots. Hope this helps. Chas. Munat
Received on Friday, 17 August 2001 18:10:28 UTC