- From: Jerry A. Silva <jassilva@ix.netcom.com>
- Date: Mon, 14 Dec 1998 23:20:06 -0800
- To: ehansen@ets.org
- CC: w3c-wai-gl@w3.org
eric hansen wrote: > I would like to respond to comments made on 12/14/98 by Charles > McCathieNevile (hereafter "CMc"). Note that "EH" indicates the responses of > Eric Hansen. > > CMc: > I am personally not keen on the idea of including elaborate impact > statements, although there are a number in the guidelines. > EH: > I don't think that impact statements in the document would necessarily need > to be more elaborate than what is included now. (Perhaps just a few > refinements might be enough.) Currently the document highlights the _major_ > affected disability groups and, in some cases, non-disability-related > groups. I see the majority of impact data as non-normative and found in > separate documents. > > CMc: > I am dead against the idea of quantifying them, as I feel that is an > exercise which > is certainly beyond the scope, and probably beyond the resources of the > WG. > EH: > I see some kind of quantification as valuable for ensuring the documents' > audiences that the circumstances of key disability groups and been examined > in the context of each guideline. I have generated draft impact ratings for > 13 disability groups for 2 of the 17 guidelines. > > CMc: > How much impact a particular problem has on the general community (as some > kind of weighted average of impacts on subsections) is, in my opinion > irrelevant to the goals of the group. It does not assist us to determine > what guideines should be followed, and what techniques are available, to > ensure that web content is accessible to all. > EH: > I think that impact ratings are one fairly stable piece of information that > would go into figuring out which techniques should be followed. > Specifically, impact ratings would be some of the information from which > priority (importance) ratings would be derived. Furthermore, the impact > ratings have the benefit of being much more focused than the priorities. > (See earlier memos.) > > CMc: > It is also important in such a situation to have > accurate, up to date information. A W3C recommendation cannot be changed - > it is by definition a stable document. [New para.] In this context, the > removal of priorities on guidelines may be helpful. The guidelines > themselves must be followed, but it may happen in some > months that there is no necessity for most people to do anything > particular to follow a given guideline, since the problem is handled for > them by an authoring tool (as an abstract example). > EH: > Since earlier memos I have supported the idea that priorities don't belong > in the normative portion of the document because they are too changeable. > One of the major motivations for proposing the idea of "impacts" is to find > a more stable indicator that might be included in the normative part (as > well as providing a firmer conceptual anchoring of the guidelines to needs > of specific disability groups). > > CMc: > The priority definitions are information which may be useful to people > trying to do a cost/benefit analysis - things which are priority 2 > techniques are not going to provide access in themselves, they are just > going to significantly improve the quality of that access (by bringing it > nearer the quality experienced by 'mainstream users' - perhaps we should > make that more explicit in the P2 definition?) while things which are > priority 1 deal with the ability to access the information or function in > any form, without minimal regard to the difficulty of using that > information or function. > EH: > I think that it is very important to make explicit how the priorities are > derived. > > If I understand the nature of priorities, I must disagree with your > characterization of "priorities" as _input_ to the calculation of > cost-benefit. My understanding has been that priorities are actually the > _output_ from a calculation (albeit informal) that uses cost-benefit types > of considerations (cost, feasibility, practicality, availability of tools, > etc.) as input. How can one generate an indicator of the priority (or > importance) related to a technique without consideration of the cost and > availability of the tools for carrying out that technique? Indeed, it is > such considerations that make priorities changeable. > > CMc: > (It could be argued that giving a person access > to a binary representation of the data in a GIF file is providing access, > but I think most people would agree that it is a stupid argument.) > EH: > That particular example might easily be dismissed, but I will propose > another one that is more realistic. > > Certain individuals who are deaf or are dyslexic can perceive the written > text, but the text is just as inaccessible to them as if they cannot > perceive it (if I am exaggerating, someone please correct me). A definition > of priorities that assigns priority 1 to issues of perception and priority > 2 to issues of language may give too little consideration to > language-related issues even though they can be barriers that are just as > severe. > > One may respond, "Yet issues of perception are more fundamental than issues > of understanding or comprehension. Issues of perception deserve to have a > higher priority than issues of understanding and comprehension." > > Yet, we should be aware that it is not very hard to recast issues of > language as issues of perception. To illustrate this, I will propose a new > technique or guideline: "If the written text is inaccessible, you must > provide an alternative accessible version of the text." > > In other words, I as an individual with a severe print-related disability > may say, "This technique is really no less important than the priority 1 > technique of providing alternative text for graphics. This technique should > be priority 1, not priority 2. The alternative, accessible text must be > made perceptible to my senses." > > By the way, this proposed technique is not that "far out." This technique > or guideline encompasses the material in A.7, at least some of the material > in B.3, part of A.5, and so on. > > ============================= > Eric G. Hansen, Ph.D. > Development Scientist > Educational Testing Service > ETS 12-R > Rosedale Road > Princeton, NJ 08541 > (W) 609-734-5615 > (Fax) 609-734-1090 > E-mail: ehansen@ets.org
Received on Tuesday, 15 December 1998 02:20:30 UTC