Suggestions

This document contains some edits. Unless dated
otherwise, they are from my 4/18/99 revision of the
4/16/99 version of the document. (That and other
revisions are available from:
http://etsr.digitalchainsaw.com/wcagpub/).

Causes for the changes are various. 

One strategic issue:

I think that there needs to be a balance between the
several different kinds of alternative representations
of information. I feel that we risk having strong
adoption on #1 because we are placing too much
emphasis on #2.

#1. Text equivalents for non-text elements (movies,
prerecorded audio, graphics, animations, applets, etc.
[1.1]).
  
#2. Text equivalents for text (linearizations of
tables [10.3], summaries for tables [5.5],
abbreviations of table headers [5.6], simplifications
of text [14.1], expansions of acronyms and
abbreviations [4.2]).

#3. Non-text equivalents for text and for non-text
elements ("graphic or auditory presentations" to
"facilitate comprehension" [14.2]; "equivalents" for
scripts, applets, etc. [6.3]; "equivalents" for
dynamic content [6.2]).

Within the last month or so we have made considerable
progress in consolidating the many checkpoints into
what is now checkpoint 1.1; refining the requirement
for linearizations of tables, and in moderating the
requirement for non-text equivalents (e.g., 14.2). I
feel that some more refinements are still needed. I
believe that modifications are still needed and well
worth making because they are likely to increase
adoption of the guidelines.

==
14.1 -- Simplified Text

Modify language to say: "Ensure readable language" or
"Define difficult vocabulary" etc. and lower the
priority to Priority 2 or Priority 3. See comments on:

http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0066.html

==
14.2 - Acronyms and Abbreviations

{EH: Delete this. I think (4/23/99, added word
"think") that this checkpoint is a "poison pill" that,
while seemingly innocuous, places an untenable burden
upon the Web developer. I think that it will
discourage an inordinate number of people from
striving for triple-AAA compliance and maybe the other
compliance levels. If it must be retained, I suggest
the following change:

4.2 Specify the expansion of first use of
abbreviations and acronyms within a document.
[Priority 3] 
For example, in HTML, use the "title" attribute of the
ABBR and ACRONYM elements. Or, provide the expansion
(especially of the first occurrence) in the main body
of the document. 
Techniques for checkpoint 4.2}

{EH: Old. 4.2 Specify the expansion of abbreviations
and acronyms. [Priority 2 for the first occurrence of
the acronym or abbreviation in a given document,
Priority 3 thereafter.] 
For example, in HTML, use the "title" attribute of the
ABBR and ACRONYM elements. Or, provide the expansion
(especially of the first occurrence) in the main body
of the document. 
Techniques for checkpoint 4.2}
==
5.4 -- Summaries for Tables
{EH: Delete this one. This should be put in the
Techniques document and be entirely optional. It
should not be required in order to obtain a triple-A
rating, unless you want to qualify that this is for
"highly complex tables."
5.5 Provide summaries for tables. [Priority 3] 
For example, in HTML, use the "summary" attribute of
the TABLE element.
Techniques for checkpoint 5.5}
==
5.5 -- Abbreviations for Header Labels

{EH: Delete this one. This should be put in the
Techniques document and be entirely optional. It
should not be required in order to obtain a triple-A
rating. 
5.6 Provide abbreviations for header labels. [Priority
3] 
For example, in HTML, use the "abbr" attribute on the
TH element.
Techniques for checkpoint 5.6}
==
6.3 --  When Scripts, etc. Turned Off

{EH: Important Bug. Delete Checkpoint 6.3. It seems
that this merely covers ground already covered by
checkpoint 1.1, which requires text equivalents for
scripts, applets, and programmatic objects. Text
equivalents from checkpoint 1.1, by definition,
provide essentially the same function and must be
available in any case. The reference to non-text
equivalents in the example is gratuitous; if we want
to say more about non-text equivalents, we should
probably do it in checkpoint 14.2. Alternative pages
are covered elsewhere. If the focus of checkpoint 6.3
is simply on ensuring that the system doesn't freeze
up, then that is simply not a disability access issue
and does not belong in the guidelines.
{EH: Old. "6.3 Ensure that pages are usable when
scripts, applets, or other programmatic objects are
turned off or not supported. If this is not possible,
provide equivalent information on an alternative
accessible page. [Priority 1] 
For example, in HTML provide a text equivalent with
the NOSCRIPT element or via a server-side script. Or
provide a non-text equivalent (e.g., a snapshot in
place of an animation, a video equivalent of an
applet, etc.). For applets and programmatic objects,
provide text equivalents. Refer also to guideline 1. 
Techniques for checkpoint 6.3 "}

==
10.4 -- Place-Holding Characters

{EH: Delete 10.4. This is one ought to be entirely
optional. This is one that seems to be an unecessary
incursion upon the visual look and feel of the system.
As I recall from a conversation with an expert
computer user who is blind, this is only a problem
related to a very old browser. I seriously advocate
removing this one. I would like us to not tamper with
the preferred look and feel of the major of Web users
unless it is absolutely essential.
10.4 Until user agents handle empty controls
correctly, include default, place-holding characters
in edit boxes and text areas. [Priority 3] 
For example, in HTML, do this for TEXTAREA and INPUT.
Techniques for checkpoint 10.4}
 ==
11.3 -- Receive According to Preferences

{EH: Checkpoint 11.3 is impossible to plan for and
should be deleted. It may be a "poison pill" because
it could create a "responsibility" nightmare for
people striving for or claiming triple-A compliance.
It would repel people from claiming triple-A
compliance. This is not essential to the success of
the guidelines and it may be essential in order to
avoid failure (at least at the triple-A level).

11.3 Provide information so that users may receive
documents according to their preferences (e.g.,
language, content type, etc.) [Priority 3] 
Note. Use content negotiation where possible.
Techniques for checkpoint 11.3}
==
13.3 -- Site Layout

13.3 Provide information about the general layout of a
site (e.g., a site map, table of contents, or
navigation bar {EH: Added navigation bar. See deletion
of checkpoint 13.5.). [Priority 2] {EH: Hopefully,
this is almost impossible not to accomplish.} 
In describing site layout, highlight and explain
available accessibility features.{EH: This sentence
must be unenforceable and should be. Doesn't this
suggestion run counter to the philosophy of universal
design? Why single out people with disabilities if it
is not necessary? I suggest putting it in the
Techniques document as something to consider.}
Techniques for checkpoint 13.3
==
13.2 -- Navigation Bars

{EH: This should be deleted. Checkpoint 13.2 has a
Priority 2 requirement for navigation. This is
redundant. If necessary, the phrase "navigation bar"
could be added to 13.3.}
13.5 Provide navigation bars to highlight and give
access to the navigation mechanism. [Priority 3] 
Techniques for checkpoint 13.5}
==
13.6 -- Grouping Related Links

{EH: This should be deleted. This could be a Technique
for 13.4 or some other checkpoint.
13.6 Group related links, identify the group (for user
agents), and, until user agents do so, provide a way
to bypass the group. [Priority 3] }
Techniques for checkpoint 13.6
{EH: This should be deleted. It is far to wide open
would not be necessary for small Web sites. This would
make another fine technique or idea to consider.
13.7 Enable different types of searches for different
skill levels and preferences. [Priority 3] 
Techniques for checkpoint 13.7}
{EH: I am ambivalent about this. It is largely
redundant with the techniques for checkpoint 14.2 and
could be deleted.}
13.8 Place distinguishing information at the beginning
of headings, paragraphs, lists, etc. [Priority 3] 
Note. This is commonly referred to as "front-loading"
and is especially helpful for people accessing
information with serial devices such as speech
synthesizers. 
Techniques for checkpoint 13.8
==
13.9 -- Document Collections

13.9 Provide information about document collections
(i.e., documents comprising multiple pages.), if
available {EH: added "if available"}. [Priority 3] 
For example, in HTML specify document collections with
the LINK element and the "rel" and "rev" attributes.
Another way to create a collection is by building an
archive (e.g., with zip, gzip, stuffit, etc.) of the
multiple pages.
Note. The performance improvement gained by offline
processing can make browsing much less expensive for
people with disabilities who may be browsing slowly.


===
Eric G. Hansen
Development Scientist, Educational Testing Service
ETS 12-R
Rosedale Road
Princeton, NJ 08541
(W) 609-734-5615, (Fax) 609-734-1090
Internet: ehansen@ets.org 
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Received on Friday, 23 April 1999 19:18:05 UTC