- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Fri, 13 Jul 2001 13:43:32 -0700
- To: "GLWAI Guidelines WG \(GL - WAI Guidelines WG\)" <w3c-wai-gl@w3.org>
NOTE TO REVIEWERS: I don’t often post long emails to the list, but this one is very important. Please read this email very carefully. Thanks. Gregg NOTE: This memo was written before the Face-to-face and some aspects have been covered in the f2f results. Those parts have been left in however, since we need to reach general consensus on these ideas with the full group. (i.e. the f2f results need to be confirmed by all the active members of the working group before we can say we have consensus) Gregg For quite some time now, I have seen our group wrestling with issues and not coming to resolutions. I’ve even seen people locked in prolonged discussions or arguments where they seem to agree at one point and then disagree on the same point later. I have seen other discussions where all of the focus seems to be on the differences rather than the common ground, which is fine, except that the common ground gets lost. It is not that the common ground isn’t ever identified when it occurs, it’s just that it is briefly noted by the writers and then is quickly swept away in the torrent of emails. This hasn’t been typical of the group in the past. Usually, we’ve had people able to step forward and propose solutions or wording that resolved issues. That isn’t happening now even though we have the same people involved in the group. So I have been looking for an underlying problem which is causing this cyclic behavior. Coupled with this has been the ever-present realization that we have been dodging the “priorities” question which we are now going to have to deal with. I believe these two are very closely related. I believe that there is probably a fairly high degree of agreement that exists or can be quickly established with regard to strategies that are helpful to everyone and strategies that are helpful to individual groups. I also believe that we probably could develop a scale of those things we think are most important, second most important, etc. to do. Where we run into problems is when we start talking about what people should do, should be required to do, or must do. We might, for example, all agree that such and such an action would be good for this group but have sharp difference of opinion about whether or not it should be required that all sites do this or all content (or even how many sites should do it for how much content). A second area of discussion seems to be whether or not the guidelines that we are writing should be 1. measures of accessibilities (e.g., rulers but not requirements) 2. recommendations (e.g., you should do this but you don’t have to) or 3. requirements (these are the things you must do in order to be accessible at the level A, level 2A or 3A level.). I therefore believe that we need to tackle the “priority” or “recommendation versus requirement” question immediately, before we are actually going to make any progress on the other fronts. RECOMMENDATION VS. REQUIREMENT Some might say that the answer is easy, that the W3C makes voluntary recommendations. That, in fact, they are even called “recommendations.” Unfortunately, that is not quite the case. Most of what the W3C creates are standards. They are voluntary standards (until somebody requires them), and they are titled “recommendations.” However, each standard has requirements which you must comply with. That is, you may voluntarily use the standard or not (unless someone else requires it); however, you must comply with the provisions if you are going to say that you used the standard. You are not allowed to, for example, say that you use html 4.0 or that you conform to html 4.0 if you only conform to those provisions which you voluntarily decide to conform to. The W3C also doesn’t condone a “percentage compliance” format. That is, the standards and their conformance statements are not structured to invite people to say that I conform to 50% of html 4.0, or just to sections a, b, and c of 4.0 but not d, e, and f. Thus, what we are doing with our guidelines is quite different from voluntary technical standards, and we need to recognize and resolve this. We do not need to do this independently. We need to do this in conjunction with both the WAI and W3C overall. However, both the WAI and the W3C are looking to this group for leadership and ideas on how to address this. WE CAN’T HAVE IT BOTH WAYS Another point that should be made here is that we need to recognize how we fit into the world overall. Specifically, we need to recognize that even though we may be creating voluntary guidelines, these guidelines may be used in regulatory arenas. This immediately raises the question of whether or not that is something that we need to worry about, or if that is something we leave to the regulatory environments to figure out. That is, we do our thing and they do theirs. However, at the same time, the W3C/WAI has been encouraging regulatory groups not to create their own separate sets of guidelines, but rather to use ours. This seems like a good idea, since having multiple sets of accessibility specifications being released by different governments, government entities and government subentities would bring chaos to companies and everyone else trying to post web pages, make their sites more accessible, or comply with local, national and international accessibility standards. But we cannot have it both ways. We cannot say that we don’t have to worry about the regulatory implications of our language (that is, requiring things), and yet say that we don’t want regulatory groups to use our guidelines. Thus, we need to either: (a) structure and word our guidelines, checkpoints, and criteria so that they can be used by those charged with setting requirements and regulations (in companies, governments, etc.) OR (b) we need to state clearly that our guidelines are not intended for use by companies or governments in setting requirements for regulations. RECOMMENDATION I do not believe that it is appropriate for us to do (b). I also think that we have to be very careful how we do (a) so that we do not accidentally wander over into the “writing regulations” territory. It is not our place to write regulations or to decide where regulatory lines should be drawn. We do, however, need to structure and write our guidelines so that they can be used effectively by those who must write requirements or regulations. I believe, therefore, our discussions should focus on that. That is, we should be focusing on how to write our guidelines so that they do not themselves assume a regulatory or requirement stance, but that they can directly be used by those who do set requirements or regulations so that we enhance consistency and harmonization across companies/governments/agencies and their requirements. This would mean that we would have to consense on a number of principles to facilitate our discussion. Let me propose some statements of principle on which we could work toward consensus to facilitate our discussions and to eliminate backtracking. The way we structure and write the guidelines should: 1. Allow people to determine when they have accessibility problems on their site. 2. Allow people to determine which problems are more serious than others. 3. Allow people to determine which problems are more serious than others for specific disability groups. 4. Be usable by companies setting requirements or governments setting regulations (in whole or in part) so that companies/governments do not have to write their own using different wording. 5. Apply to all content on all websites except as noted (i.e., if they are not intended to apply to some types of content that it is so stated.). 6. Provide objective criteria wherever possible. 7. Not exclude items for which objective criteria are not available [even though regulatory entities may have to exclude them or make them advisory]. I have tried to pick things which I think we might be able to consense on or consense on with edits. I’m going to maintain a list of such principles or decisions as a separate document. This document will have three sections: 1 principles we’ve consensed on; 2 candidate principles; and 3 clearly no consensus. In general, I don’t think it’s useful to have a lot of things in the bottom category. However, it may turn out that sometimes it is helpful to clearly establish that there is no consensus so that we don’t have to churn the list reestablishing this periodically. Again, the purpose of this document will be to help us find common ground and to clearly identify those things which we do agree on. Occasionally, I have seen large sections of listserve making a plea for something which I haven’t seen anyone speak against. Let's document these as being in agreement and save our list serve discussions for other aspects. This list of principles can also help to document some things which will never go directly into the guidelines but which are important for us to understand and agree on in order to effectively develop the guidelines. If people have nominations for the list, please send them to the listserv. I will maintain this document for a while and see if it, in fact, is helpful. Gregg Postscript I wrote the memo above prior to the Face to Face We tried this approach at the Face to Face and it seemed to be very helpful. We early on determined that we needed to look at some big issues that had to be answered first before we could make any real progress. We posted those to the list Monday. In a separate memo I will post the latest update on these from day 2. We look to comments on these and the items above. -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Human Factors Dept of Ind. Engr. - U of Wis. Director - Trace R & D Center Gv@trace.wisc.edu <mailto:Gv@trace.wisc.edu>, <http://trace.wisc.edu/> FAX 608/262-8848 For a list of our listserves send “lists” to listproc@trace.wisc.edu <mailto:listproc@trace.wisc.edu>
Received on Thursday, 13 September 2001 16:43:42 UTC