Responses and Revisions -- Part 1

Date: 12 January 1999, 12:48 hrs
To: PAGL Listserv
From: Eric Hansen (EH)
Re: Responses and Revisions

This memo has two parts: (1) responses to questions and comments  and (2) 
suggested revisions to the PAGL document.

I feel that the material in Part 2 addresses many of the questions and 
comments that been posed to me. I hope that it helps.

PART 1: RESPONSES TO QUESTIONS AND COMMENTS

>>>1. Impact is the Determiner of Imperative (Priority)

Gregg Vanderheiden has affirmed that "The impact IS the determiner of the 
imperative." With that in mind, I feel strongly that the document needs to 
make this point clearer. Specifically, the priority definitions should 
state clearly that: "This checkpoint (must, should, may) be addressed by an 
author BECAUSE failure to do so would result in one or more groups of users 
finding it (impossible, very difficult, somewhat difficult) to access 
information in the document." The word BECAUSE, which I capitalize for 
emphasis in this memo, makes clear the logical relationship between impact 
and imperative. This revised wording is reflected in Part 2.

>>>2. Language Related-Disabilities

These last rounds of memos have elicited a variety of rationales for the 
exclusion or near exclusion of checkpoints (formerly "techniques") relating 
to language-related disabilities, in addition to other issues (e.g., 
cultural, sensitivity, legal, economic, marketing issues).

In response to Eric Hansen's observation that "many other issues that could 
well be addressed in the guidelines (e.g., language, cultural, sensitivity, 
legal, economic, marketing, etc.)", Gregg Vanderheiden (GV) wrote: "The 
reason these were not included is not because of cost issues.  It is 
because these are not disability access issues.   A person with a 
disability is not denied access to the information because of cultural or 
sensitivity issues etc any more than a person without a disability.  The 
focus of the guidelines is on accessibility not on good design. (though we 
were sorely tempted to put some good practices into the guidelines that 
were not access oriented, we either resisted or ended up pulling them back 
out)."

EH now writes: 

I think that perhaps the strongest counter-example to the idea that these 
are not disability access issues is, as Gregg Vanderheiden also noted, in 
the area of cognitive disability: "Cognitive is probably the toughest one.  
We have techniques for people with no sight or no hearing or even physical 
movement.  But we have no solutions for providing access to most content on 
the web for people who have no cognitionþ. Or almost no cognitionþ or even 
moderate to severe impairment of cognition.   This area starts to move from 
how the information is presented to the content of the information itself."

On what basis could one reject a checkpoint such as the following 
checkpoints that address a disability access issue for people with 
cognitive or other disabilities?

Problem: Individuals with language-related disabilities (cognitive 
disabilities, learning disabilities, deafness, etc.) often have difficulty 
accessing written text even when it can be perceived.

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)
2. Employ other non-textual means to communicate the message. For example, 
present the message in visual media (still or motion pictures) such as the 
content being signed by someone skilled in a manual signing system. [Note. 
This may address the situation of the deaf nonreader. 
(http://lists.w3.org/Archives/Public/w3c-wai-gl/1998OctDec/0366.html) 
(Priority 1)
3. (A.7.1) Clearly identify changes in the language of text (e.g., the HTML 
"lang" attribute) [Priority 2].  (This can help cue automated translation 
systems as well as humans regarding the source language.) 
4. (A.7.2) Specify the expansion of abbreviations and acronyms (e.g., with 
the "title" attribute of the HTML ABBR or ACRONYM elements). [Priority 2] 

>>>Scope and Limitations

EH wrote: "(#3.) Minimize accusations of bias by telling the truth about 
the document's scope and limitations. Provide a principled rationale or 
justification for the exclusions. I don't think that this is that hard to 
do. It just has to be done."
GV:  "Made an edit to address the example you cited.  Are there others?"

EH's Current Comment:

It has been harder to explain the scope and limitations than I had thought, 
but Part 2 contains my attempt. Obviously, I am making some assumptions in 
doing so. If my assumptions are wrong, I would appreciate being corrected.


=============================
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, 12 January 1999 17:48:34 UTC