Revision to Guideline 16; Nonreaders; Reference Groups

Following are suggested changes to Guideline 16 and its checkpoints and 
techniques.

Guideline 16. Provide clarity and consistency. {EH: Changed.}

Provide clarity and consistency to promote comprehension. {EH: Changed. One 
can easier validate that someone "provided" clarity than that they 
"designed for" clarity.}

Consistent page layout, recognizable graphics {EH: Deleted the word "icon", 
so as to not confuse with "button"}, and easy to understand language 
benefit all who visit a site. In particular, they help people with 
cognitive disabilities or who have difficulty reading. (However, ensure 
that images have text equivalents for people who are blind, have low vision,
 or for any user who cannot or has chosen not to view graphics. See also 
guideline 1. ){EH: Parens added. Should other guidelines also be cited?} 

Using clear and simple language promotes effective communication {EH: 
wording modified slightly}. Conditions such as cognitive disabilities, 
learning disabilities, and deafness can make access to written information 
difficult to impossible for some users {EH: Revised. Mentions learning 
disabilities.}. This consideration also applies to the many people whose 
first language differs from your own. 

Checkpoints:

16.1 Use language that is as clear and simple as possible, while 
appropriate for the site's content.  [Priority 1] {EH: Added "clear" to 
emphasize comprehension (clarity) over simplicity. A string of simple 
(short) sentences may be LESS easily understood than a longer, more complex 
sentence. 2/26/99: "Use language that is as simple as possible, while 
appropriate for the site's content.  [Priority 1]".} 
===
{EH: :New suggested Technique for checkpoints 16.1:}

Provide a simplified text equivalent as an alternative to the main {EH: or 
"regular"} text. This may be helpful to nonreaders and people who have 
difficulty reading. Nonreaders can hear the simplified text using speech 
output technology. Individuals with reading difficulties may be able to 
read the simplified text. Because of the challenges of maintaining separate 
texts, a better approach will often be to simplify only the main text and 
not have a simplified text equivalent.

{EH: As a Technique, I think that this is a reasonable addition and perhaps 
an essential addition. The technique is a way of making sure the language 
is "clear" and "simple."

An alternative approach would be to add a checkpoint at the Priority 2 
level because violations will make it more difficult for people with 
cognitive disabilities, learning disabilities, and deafness to access the 
information. (By the way, if this were to become a checkpoint as opposed to 
a technique, the wording of 16.1 would need to be slightly modified.) 
Unfortunately, at this point, I consider this too impractical to recommend 
for the group of all Web developers. In my opinion, no checkpoint should be 
extremely impractical (or likely to remain impractical for the next 5 years 
or so). I think that it makes sense to add this to the Techniques document 
because people can pick or choose their approaches and this is a viable 
approach is some settings.

As I have argued before, while issues of cost, feasibility, and 
practicality should not influence the Priority assigned to a checkpoint, 
they can and must influence whether or not a checkpoint is included.}   
==== 

{EH: I suggest an expansion of the scope of checkpoint 16.2. The old 
(2/26/99) version of 16.2  reads:   "Use icons or graphics (with a text 
equivalent) where they facilitate comprehension of the page. [Priority 3]"} 

{EH: My suggested revision to 16.2 is:} 

16.2 Provide nontext equivalents (in addition to text equivalents) where 
they facilitate comprehension of the page. [Priority 2]. These are 
especially important for nonreaders. (See guidelines 1 through 3 {EH: Not 
sure how many to include} for information on text equivalents.) {EH: 
Changed from a Priority 3 to a Priority 2 since violation of this 
checkpoint will make users with cognitive disabilities, learning 
disabilities, and deafness more difficult to access the information.}{EH: 
One could arguably delete the phrase: "where they facilitate comprehension 
of the page"... but I have chosen not to at this point.}   
Visual nontext equivalents may include, for example graphics, animations, 
or videos. These are especially helpful for nonreaders who can perceive 
visual presentations. For example, sighted deaf nonreaders may benefit from 
video equivalents in manual communication (sign language). Nonreaders, 
whether they have disability or not, may also benefit from highly graphical 
equivalents. 

Nonvisual nontext equivalents are very diverse. Among the most common are 
prerecorded audio of music, spoken language, or sound effects. Such 
equivalents would be especially important for nonreaders who can perceive 
audio presentations. Presentations in the audio medium of synthesized 
speech and the tactile medium of braille are usually derived from text or 
text equivalents so usually require no additional work from the developer. 
{EH: I am not sure about the semantics of "equivalents" being "derived" 
from other "equivalents", but this is my current suggestion.} Smell- or 
taste-based equivalents are theoretically possible for limited types of 
content. 

{EH: If I am correct, checkpoints 16.2, 16.1, and 8.5 are the checkpoints 
that most nearly deal with access by nonreaders with deafness, dyslexia, or 
cognitive disabilities. It seems to me that the only grounds for not rating 
these checkpoints as Priority 1 is that there is not a group called 
"nonreaders" or "nonreaders with [ deafness OR dyslexia OR cognitive 
disability ]"  on the list of disability groups addressed by this document. 
(As of yet, the list of disability groups has not been explicitly set forth 
by the working group.)  These checkpoints seem to be the only ones that 
address the needs of people for whom written text is not the best core 
representation of information.}

{EH: Someone on the list recently pointed out that the guidelines are 
oriented to groups, not individuals. While the end goal is definitely to 
help individuals, I don't see any way around having a well-defined 
reference set of disability groups. Otherwise there is no way to produce 
relatively stable Priority ratings. (Impact [on disability groups] 
determines Priority.)  Unless one defines the set of reference groups, one 
doesn't really know the meaning of the Priorities. The longer the list of 
disability groups, the greater the likelihood that a given checkpoint will 
be assigned a Priority 1 rating. It is theoretically possible, if each 
person with a disability constituted its own group, that all our present 
checkpoints and many more would be rated Priority 1. Of course, at that 
point the ratings would be meaningless.}
==== 

16.3 Create a style of presentation that is consistent between pages.  
[Priority 3] {EH:Revised. Clarifies meaning.} {EH: Old. 16.3 Create a 
consistent style of presentation between pages.  [Priority 3]} 


=============================
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 Friday, 12 March 1999 14:24:43 UTC