W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 1998

remove

From: Jerry A. Silva <jassilva@ix.netcom.com>
Date: Mon, 14 Dec 1998 23:20:06 -0800
Message-ID: <36760DA5.27549564@ix.netcom.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:46:58 GMT