- From: eric hansen <ehansen@ets.org>
- Date: Wed, 13 Jan 1999 11:23:11 -0500 (EST)
- To: w3c-wai-gl@w3.org
***1. In response to Eric Hansen's suggested guideline and checkpoints: > Suggested Guideline: "If a written text is inaccessible due to the > difficulty of the language, provide an alternative representation or > version that is accessible. > > Checkpoints: > 1. Provide a less complex and less difficult textual version. (Priority 1) Daniel Dardailler wrote: "Note that some of the checkpoints you mention are valid regardless of this guidelines, because they do relate to access to the information (e.g. if lang=fr is not used when a voice agent read my last name, you will get a false reading), but "Provide a less complex and less difficult textual version" is just not feasable."" Eric Hansen now writes: I agree that feasibility is an important consideration. I had at least two purposes in proposing this guidelines and its checkpoints: first, to heighten awareness of issues faced by people with language-related disabilities; second, to drive home the point that issues of cost (feasibility, practicality, cost-effectiveness) did, do, and should play a role in developing the guidelines. I understand now that priorities (imperatives) are functionally determined by impacts, without consideration of other factors such as cost. However, I have argued that the cost of implementing a solution did and should influence the decision of whether or not to include a checkpoint (or guideline) in the list. If the costs of implementing a solution seems too high to recommend to all Web authors, then it seems to me that the working group can assert that the solution must be excluded from the document for that reason. In fact, excluding the excessively expensive checkpoint is the ONLY thing that the working group CAN do. If the conceptual framework for the priorities were different there would be a different way out of this problem. You may recall that some while ago I advocated making clear that impact and imperative can vary independently. If they were allowed to vary independently, one could give an expensive but essential checkpoint a HIGH impact rating (e.g., PREVENTS access by people with cognitive disabilities) but a low priority rating (e.g., Web authors MAY do). But this is not permitted. The guidelines document can ONLY include checkpoints that are believed to be economically feasible for virtually all Web authors. Otherwise you find yourselves in the untenable situation of recommending a solution that you believe is NOT cost-effective. At this point, I don't recommend changing the way in which the priority (imperative) ratings are produced. I just recommend making explicit the grounds for excluding any given checkpoint. "Excessive cost" or "lack cost-effectiveness" can and must be justifiable reasons for excluding a checkpoint or guideline from the document. ***4. Daniel Dardailler wrote: "To give you a direct example, I bet some readers of this list will find your most recent posting inaccessible, semantics wise, because of its length. Are you willing to rewrite it so that it fits on a single page (e.g. less than 40 lines) ?" Eric Hansen now writes: I apologize for the length. If it would be helpful to the working group, I would be willing to try to reduce the length. I know that writing or rewriting good text can be hard labor. Perhaps rewriting Web text may only be warranted in Web sites for specific purposes or audiences. But as noted in my material in Part 2, the checkpoints and the guideline document as a whole is addressed to general audiences (especially individuals with disabilities) across a wide spectrum of purposes, and therefore may not be sensitive to every specific audience or content purpose. ============================= 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 Wednesday, 13 January 1999 12:48:52 UTC