Suggestions Regarding Checkpoint 1.1

Suggestions Regarding Checkpoint 1.1

Checkpoint 1.1 is arguably the most important checkpoint in the guidelines. 
This memo is intended to allow easier comparison of old and suggested 
versions. The suggested version is presented in two forms -- (Part 1.B) 
Without Comments and (Part 1.C) With Comments.

Glossary terms (my definitions) are provided at the bottom of this 
document. 

This and other material is documented at:

http://etsr.digitalchainsaw.com/wcagpub/r990324b.htm

Except for changes marked with ## or $%, the following is the same as the 
4/6/99 material posted last week. 
(http://etsr.digitalchainsaw.com/wcagpub/r990324ahtm)

Part 1 - Checkpoint 1.1

A. Old 3/24/99 Version of Checkpoint 1.1

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", 
"longdesc", or in element content). This includes: images, graphical 
representations of text, image map regions, short animations (e.g., 
animated GIFs), applets, ascii art, frames, scripts, inserted list bullets, 
sounds (played with or without user interaction), stand-alone audio files, 
synthesized speech, audio tracks of video, and video. [Priority 1] 
For example, in HTML: 
· Use "alt" for the IMG, INPUT, and APPLET elements, or provide equivalent 
information in the content of the OBJECT and APPLET elements. 
· For complex elements where the "alt" text does not suffice, provide an 
additional description using, for example, "longdesc" with IMG or FRAME, a 
link inside an OBJECT element, or a description link in the document. 
· For image maps, use the "alt" attribute with AREA, or the MAP element 
with A elements and rich description as content.

==

B. Suggested Version Without Comments

{EH:$%. Here is the Suggested Revision WITHOUT the comments.}

1.1 Provide a text equivalent for the following non-text communication 
elements:  
· images (including pictures of text)
· image map regions
· animations (e.g., animated GIFs)
· applets and programmatic objects 
· ASCII art (see checkpoint 13.10)
· frames (See also checkpoints 12.1 and 12.2.)
· scripts 
· inserted list bullets
· audio, e.g.,
· sounds (played with or without user interaction)
· prerecorded audio (e.g., standalone audio files, audio tracks of video)
· video  
· any other _important_ communication element (including those that rely on 
visual, tactile, auditory, or other senses) that cannot be rendered in each 
of the three required text-based ways. (For example, a synthesized speech 
element would require a text equivalent if the same purpose or function 
could not additionally be provided in the other two text-based ways. Such 
cases would be rare, since synthesized speech often already has an 
underlying text representation that could also be rendered in braille or 
visually-displayed text.)
[Priority 1] 
For example, in HTML: 
· Provide a text equivalent in the "alt" attribute for the IMG, INPUT, and 
APPLET elements.
· Provide a text equivalent in the content of the OBJECT and APPLET 
elements. 
· For complex elements where the "alt" text does not not provide a complete 
text equivalent, provide an additional description using, for example:
1. "longdesc" with IMG or FRAME, 
2. a link inside an OBJECT element, or 
3. a description link in the document. 
· For image maps:
1. use the "alt" attribute with AREA, or 
2. the MAP element with A elements and rich description as content.
Note 1. Text equivalents for acronyms and abbreviations are addressed in 
_checkpoint 4.2_.  {EH: Could move 4.2 to this guideline.}
Note 2. Text equivalents for non-W3C-formatted documents and text 
equivalents as alternative accessible pages are addressed in _guideline 
11_. 
Techniques for checkpoint 1.1
=====
C. Suggested Version With Comments

{EH:$%. Here is the Suggested Revision WITH the comments.}
Here is the commented version:
1.1 Provide a text equivalent for the following non-text communication 
elements: {EH: An alternative would be to say "Provide a text equivalent 
for every non-text communication element, including the following:", though 
that may lead to focusing excessively on the smaller potential 
communicational elements (e.g., alt-text attribute values) or very large 
ones (e.g., whole  pages or may be "communication elements."). It is the 
midde-sized ones that should be the focus of this checkpoint. We should 
just try to make this list as complete as possible. Partial accommodation 
for the potentially large scope of the concept of text equivalent is 
provided in Note 2 below in this checkpoint.} {EH: I have reformatted the 
material into lists. It is perhaps not essential but it seems to make it 
easier to read, visually at least...} 
· images (including pictures of text)
· image map regions
· animations (e.g., animated GIFs) {EH: Delete the word "short." Are not 
text equivalents just as needed for long animations as short ones?} 
· applets and programmatic objects {EH: Added programmatic objects. Like 
6.3. Is this correct?}
· ASCII art (see checkpoint 13.10 {EH: crossref})
· frames {EH: I am not sure how to developer text equivalents of frames.} 
(See also checkpoints 12.1 and 12.2. {EH: Is there something more on this 
is the techniques document?})
· scripts 
· inserted {EH: Is this a correct term?} list bullets
· audio, e.g.,
· sounds (played with or without user interaction)
· prerecorded audio (e.g., standalone audio files, audio tracks of video)
· {EH: Is real-time audio (streaming or broadcast) different because it is 
just not feasible?}
· video  {EH: Does this include real-time video (streaming or broadcast) or 
is it different because it is just not feasible?}
· {EH: What about 'markup languages' like "MathML"? Not to worry? Are these 
counted as "scripts"?}
· {EH: Is there any possibility that 'forms' or input elements or 
interactive entities should also be included in this list?}
· {EH: Note that the reference to synthesized speech was deleted. If it is 
included, it must be with explanation as in the "Note to Editors" 
immediately below. To list it without explanation would cause great 
confusion.}
· any other _important_ {EH: One could delete the word "important" but 
without it, the statement seems too all-inclusive} communication element 
(including those that rely on visual, tactile, auditory, or other senses) 
that cannot {EH: ##4/9/99: Deleted redundant word "lack"} be {EH:$%, 
4/13/99. Deleted the word "properly"} rendered in each of the three 
required text-based ways. (For example, a synthesized speech element would 
require a text equivalent if the same purpose or function could not 
additionally be provided in the other two text-based ways. Such cases would 
be rare, since synthesized speech often {EH: or "usually" or "almost 
always"??) already has an underlying text representation that could also be 
rendered in braille or visually-displayed text.) {EH: New added.}
[Priority 1] 
For example, in HTML: 
· Provide a text equivalent in the "alt" attribute for the IMG, INPUT, and 
APPLET elements.
· Provide a text equivalent {EH: Deleted "information" since it can only 
muddy the definition of equivalent} in the content of the OBJECT and APPLET 
elements. 
· For complex elements where the "alt" text does not not provide a complete 
text equivalent {EH: Replaces "not suffice" with "not provide a complete 
text equivalent"}, provide an additional description {EH: Implies that 
description can be the stuff of text equivalents. That is OK as long as we 
are consistent in the use of the term.} using, for example:
1. "longdesc" with IMG or FRAME, 
2. a link inside an OBJECT element, or 
3. a description link in the document {EH: Are not all these things "in the 
document"?}. 
· For image maps:
1. use the "alt" attribute with AREA, or 
2. the MAP element with A elements and rich description {EH: Is "rich 
description" a technical term? I cannot evaluate the material from "..or 
the MAP..." to the end of the sentence.} as content.
Note 1. Text equivalents for acronyms and abbreviations are addressed in 
_checkpoint 4.2_.  {EH: Could move 4.2 to this guideline.}
Note 2. Text equivalents for non-W3C-formatted documents and text 
equivalents as alternative accessible pages are addressed in _guideline 
11_. {EH: It seems to me that most, if not all, accessible Web pages may be 
construed as text equivalents. I don't feel as strongly about the necessity 
of this note as I do of Note 1.}
{EH: One could introduce the concept of "partial text equivalents" such as 
summaries of tables, but this is probably not essential.}

{EH: Locations of Text-Equivalents. In my view, the guidelines document 
suggests locations for the text equivalents to be stored but does not 
mandate locations, unless those locations are specified in the actual 
checkpoint statement (which ends just prior to the priority level of the 
checkpoint). This means that the Techniques document bears the burden of 
making those requirements. If I am wrong in this assumption, then I would 
like to know about it. My feeling at this point is that Web developers 
should have a lot of latitude in the locations for text equivalents. If 
people choose to use other locations or mechanisms for storing equivalents, 
they can do so, though it makes it harder to validate conformance, since 
automated methods might not know where to look of the equivalent. I will be 
interested to see the new draft of the Techniques document.} 
Techniques for checkpoint 1.1

====
Part 2 - Short Definitions (My Revisions)

Equivalent

An "equivalent" is a communication element that, when presented to the user,
 fulfills {EH:4/12/99 ##, instead of "provides"} essentially the same 
communication purpose or function as one or more other communication 
elements.

Communication Element.

A communication element is a coherent piece of information that bears 
content for delivery to users.  For any given communication element, there 
may be more than one way of presenting (rendering) its "message" in order 
to fulfill the element's communication purpose or function. For example, a 
text communication element might be presented or rendered as synthesized 
speech, braille, or visually-displayed text. One communication element may 
contain other communication elements. Interactivity may be an essential 
aspect of some communication elements.

Text Communication Element. 

A text communication element can be rendered (presented) {EH:4/12/99.## 
Removed the word: "effectively} in at least three distinct text-based ways 
-- synthesized speech, braille, and visually-displayed text.  Text 
communication elements are usually written in text characters in a _natural 
language_ or a close variant. {EH: A simple HTML document is usually if not 
always a text communication element. It contains natural language plus 
markup, thus making it a variant of natural language.}When text 
communication elements are presented to users, they often conform even more 
closely to natural language. {EH: When an HTML document is presented to the 
user visually, it conforms even more closely to natural language because 
all you see is natural language and formatting.}{EH: I think that the last 
couple of sentences are important. First, they make it clear that we do not 
mean "1"s and "0"s, even though they are also "text." Second, they 
underscore the definition of text communication element as pertaining to 
natural language.}

A Non-Text Communication Element. 

{EH: Important issue: Note that this term replaces the term "non-text 
element" in checkpoint 1.1.}. A non-text communication element can be 
rendered {EH:## 4/12/99. Removed "effectively"} in at least one way but 
fails to render properly in at least one of the three required text-based 
ways (synthesized speech, braille, and visually-displayed text). Examples 
of a non-text communication elements may include images, icons, prerecorded 
audio, and video.

Equivalent

An "equivalent" is a communication element that, when presented to the user,
 fulfills {EH:4/12/99 ##, instead of "provides"} essentially the same 
communication purpose or function as one or more other communication 
elements.

Text Equivalent

A text equivalent is an equivalent that can be rendered {EH:4/12/99##. 
Deleted the word "effectively" since that is implied.} in three text-based 
ways (synthesized speech, braille, and visually-displayed text).

Non-Text Equivalent {EH: Important issue: Note that this is a new 
definition of non-text equivalent. The old definition simply did not hang 
together.}. 

A non-text equivalent is an equivalent that is not a text equivalent. In 
other words, non-text equivalent is an equivalent that can be rendered 
{EH:4/12/99##. Deleted the word "effectively" since that is implied.} in at 
least one way, but fails to render {EH:4/12/99##. Deleted the word 
"effectively" since that is implied.}in at least one of the three 
text-based ways (synthesized speech, braille, and visually-displayed text). 
An audio clip of a person speaking a text aloud may serve as an non-text 
(auditory) equivalent for written text.



=============================
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, 13 April 1999 17:03:17 UTC