Bug Fixes for Definitions of 'Equivalent' and 'Text Content', (et c).

Definitions of Equivalent and Text Content, etc.

Per my mention on the telecon today, the following are bug fixes for the
definitions of Equivalent and Text Content (etc). Some of the discussion
material below should be helpful in examining the concept of Equivalency. 

Suggestion 1: Clarify the definition of Equivalent.

Old (16 October editors' draft, perhaps identical to 29 September 2000
draft):

Equivalents (for content) 
In the context of this document, an equivalency relationship between two
pieces of content means that one piece -- the "equivalent" -- is able to
serve essentially the same function for a person with a disability (at least
insofar as is feasible, given the nature of the disability and the state of
technology) as the other piece -- the "equivalency target" -- does for a
person without any disability. For example, the text "The Full Moon" might
convey the same information as an image of a full moon when presented to
users. Note that equivalent information focuses on fulfilling the same
function. If the image is part of a link and understanding the image is
crucial to guessing the link target, an equivalent must also give users an
idea of the link target. 
Equivalents include text equivalents (long and short, synchronized and
unsynchronized) and non-text equivalents (e.g., an auditory description, or
a visual track that shows a prerecorded sign language translation of a
written text, etc.). 
Each markup language defines its own mechanisms for specifying equivalents.
For instance, in HTML 4 [HTML4] or SMIL 1.0 [SMIL], the "alt" attribute
specifies a text equivalent for many elements. In HTML 4, authors may
provide equivalents in attribute values (e.g., the "summary" attribute for
the TABLE element), in element content (e.g., OBJECT for external content it
specifies, NOFRAMES for frame equivalents, and NOSCRIPT for script
equivalents), and in prose. Please consult the Web Content Accessibility
Guidelines 1.0 [WCAG10] and its associated Techniques document
[WCAG10-TECHS] for more information about equivalents.

New (This edited version uses <<** changed material (or note)**>> to
indicate changed material.)

Equivalent<<**(made singular)**>> (for content) 

In the context of this document, an equivalency relationship between two
pieces of content means that one piece -- the "equivalent" -- is able to
serve essentially the same function for a person with a disability (at least
insofar as is feasible, given the nature of the disability and the state of
technology) as the other piece -- the "equivalency target" -- does for a
person without any disability. For example, the text "The Full Moon" might
convey the same information as an image of a full moon when presented to
users. If the image is part of a link and understanding the image is crucial
to guessing the link target, <<**then the **>>equivalent must also give
users an idea of the link target. Note that equivalent information focuses
on fulfilling the same function. <<** Editor's note. Order of last two
sentences was switched.**>>

<<**Equivalents include text equivalents (e.g., short and long text
equivalents for images; text transcripts for audio tracks; collated text
transcripts for multimedia presentations and animations) and non-text
equivalents (e.g., a prerecorded auditory description of a visual track of a
movie, or a sign language video rendition of a written text, etc.). (See
definitions of _text equivalent and non-text equivalent_.**>>

Each markup language defines its own mechanisms for specifying equivalents.
For instance, in HTML 4 [HTML4] or SMIL 1.0 [SMIL], the "alt" attribute
specifies a text equivalent for many elements. In HTML 4, authors may
provide equivalents <<** insert: "or portions of equivalents"**>> in
attribute values (e.g., the "summary" attribute for the TABLE element), in
element content (e.g., OBJECT for external content it specifies, NOFRAMES
for frame equivalents, and NOSCRIPT for script equivalents), and in prose.
Please consult the Web Content Accessibility Guidelines 1.0 [WCAG10] and its
associated Techniques document [WCAG10-TECHS] for more information about
equivalents.

Comment 1-1:

I removed reference to synchronized and unsynchronized equivalents. I would
rather not imply that synchronized and unsynchronized equivalents are
different "kinds" of equivalents. I would rather think of synchronization
information as simply part of the structural markup that may be part of an
equivalent. Please note that the notion of regarding synchronization
information as part of structural markup and therefore simply part of what
can be included in a text or non-text element is something that I have not
seen discussed and that may be helpful in the future. 

Comment 1-2:

I changed "an auditory description" to "a prerecorded auditory description
of a visual track of a movie". To be consistent with the current wording of
WCAG 1.0 checkpoint 1.1, we need to treat these elements (text elements and
non-text elements) as "pre-rendering content". Thus, it would _not_ be
correct to refer to synthesized speech auditory descriptions as a non-text
equivalent, since synthesized auditory descriptions are "post-rendering
content". Synthesized speech auditory descriptions are produced from text
equivalents with proper structural (synchronization) markup. Therefore, to
not give a wrong impression, we must delimit this discussion of non-text
equivalents to "prerecorded auditory description". Finally, the phrase "of a
visual track of a movie" makes it parallel to the ASL example by naming the
equivalency target. 

If the re-wording of WCAG checkpoint 1.1 comes up for consideration, we
could revisit this issue. For example, if the wording was to be: "Ensure
that every non-text element has a text equivalent" and we wanted "elements"
to include "post-rendering" content, then we would need to revisit this, but
at this point, I don't see the need to do so. 

Comment 1-3:

I have referred the readers to the definitions of text equivalent and
non-text equivalent for more information.

Comment 1-4:

I used the word "rendition" instead of "translation" when referring to the
ASL video. This is to reduce confusion with the 'translation" associated
with internationalization. I want to focus on accessibility, not
internationalization. The term rendition was also preferred by a colleague
who is deaf and with whom I have done research involving such sign language
videos. Still if you still prefer translation, go ahead.

Comment 1-5:

In the first paragraph I switched the order of the last two sentences and
made a wording change to make clearer that the information about the link
target is _part of_ the equivalent.

Comment 1-6:

In the last paragraph I have inserted the phrase "or portions of
equivalents" since there are at least some cases in which a summary of a
table would _not_ be considered a full equivalent for a table.

====

Suggestion 2: Clarify the definition of "Non-text content" etc.

Old (16 October editors' draft, perhaps identical to 29 September 2000
draft):

Text content, Non-text content, text element, non-text element, text
equivalent

In this document, the term "text element" means content that, when rendered,
is understandable in each of the three modes:

1. visually-displayed text (e.g., for a user who is deaf and adept in
reading visually-displayed text); 
2. synthesized speech (e.g., for a user who is blind and adept in use of
synthesized speech); 
3. braille (e.g., for a user who is deaf-blind and adept at reading
braille). 

A text element may contain markup for structure (e.g., heading levels), and
style (e.g., font size or color), etc. However, the essential function of
the text element should be retained even if style information happens to be
lost in rendering. In this document, the term "text content" refers to
content that is composed of one or more text elements.

A "non-text element" is an element that fails to be understandable when
rendered in any of three modes to their respective disability audiences.
Note: In these definitions, the term "understandable" means understandable
by representatives of the reference disability groups (deaf, blind,
deaf-blind) who are operating under reasonable conditions (i.e., they have
the appropriate available hardware and software), who able to understand the
natural language of the content, who are not experts in computer science,
etc.

In this document, the term "non-text content" refers to content that is
composed of one or more non-text elements. Per checkpoint 1.1 of "Web
Content Accessibility Guidelines 1.0" [WCAG10], authors must ensure that
there is a "text equivalent" for each author-supplied non-text element.
Similarly, user agent developers must ensure that a text equivalent is
available for any non-text element produced by the user agent for the user
(refer to checkpoint 1.5).

A "text equivalent" is a text element that, when rendered, serves
essentially the same function as some other content (i.e., an equivalency
target) does for a person without any disability (see definition of
equivalents).

Note that the terms "text element" and "non-text element" are defined by the
characteristics of their output (rendering) rather than those of their
input. For example, in principle, a text equivalent can be generated or
encoded in any fashion as long as it has the proper output characteristics.
In general, text elements are composed of text (i.e., a sequence of
characters). A text equivalent may be understood as "pre-rendering" content
in contrast to the "post-rendering" content that it produces
(visually-displayed text, synthesized speech, braille).

New:

Text content, <<**n**>>on-text content, text element, non-text element, text
equivalent, <<**non-text equivalent**>>

In this document, the term "text element" means content that, when rendered,
is understandable in each of <<**(Delete: "the")**>> three modes <<** to a
reference disability group **>>:

1. visually-displayed text <<(deleted "i.e.," and parentheses)**>>for a user
who is deaf and adept in reading visually-displayed text; 
2. synthesized speech <<(deleted "i.e.," and parentheses)**>>for a user who
is blind and adept in use of synthesized speech; 
3. braille <<(deleted "i.e.," and parentheses)**>>for a user who is
deaf-blind and adept at reading braille. 

A text element may contain markup for structure (e.g., heading levels), and
style (e.g., font size or color), etc. However, the essential function of
the text element should be retained even if style information is <<**ignored
**>>in rendering. In this document, the term "text content" refers to
content that is composed of one or more text elements.

A "non-text element" is an element that fails to be understandable when
rendered in any of three modes to their respective <<**reference**>>
disability audiences. Note: In these definitions, the term "understandable"
means understandable by representatives of the reference disability groups
(deaf, blind, deaf-blind) who are operating under reasonable conditions
(i.e., they have the appropriate available hardware and software), who able
to understand the natural language of the content, who are not experts in
computer science, etc.

In this document, the term "non-text content" refers to content that is
composed of one or more non-text elements. Per checkpoint 1.1 of "Web
Content Accessibility Guidelines 1.0" [WCAG10], authors must <<** provide a
text equivalent for every author-supplied non-text element **>>. Similarly,
user agent developers must <<** provide a text equivalent for every non-text
element **>> produced by the user agent for the user (refer to checkpoint
1.5).

<<** The following paragraph has been switched with the next paragraph.
Also, the first sentence has been added.**>>
Thus, text elements have essential accessibility advantages often associated
with "text" while non-text elements are those that lack one or more such
advantages. Note that the terms "text element" and "non-text element" are
defined by the characteristics of their output (rendering) rather than those
of their input. For example, in principle, a text equivalent can be
generated or encoded in any fashion as long as it has the proper output
characteristics. In general, text elements are composed of text (i.e., a
sequence of characters). <<**Both text elements and non-text elements
should**>> be understood as "pre-rendering" content in contrast to the
"post-rendering" content that it produces (visually-displayed text,
synthesized speech, braille).

A "text equivalent" is a text element that, when rendered, serves
essentially the same function as some other content (i.e., an equivalency
target) does for a person without any disability (see definition of
equivalents).


Comment 2-1:

I changed the third to the last paragraph (<<** provide a text equivalent
for every author-supplied non-text element **>>) to bring it into closer
alignment with WCAG 1.0 checkpoint 1.1. Again, if the wording of checkpoint
1.1 may be revised, this wording might likewise be revisited.

Comment 2-2:

In the list of three renderings (visually displayed text, synthesized
speech, and Braille), I deleted the term "i.e.," (and parentheses) because
these are _not_ merely "examples" of groups that might find the content
understandable, these are _the_reference groups. Indeed, to leave the
"i.e.," would contradict the specific mention of those reference groups only
two paragraphs later ("reference disability groups (deaf, blind,
deaf-blind)"). To say "e.g." is to imply that there may be a long (but
undefined) list of groups that _must_ find it understandable. By making
demands that are unreasonably open-ended and large one can weaken a
requirement just has much as one can by making demands that are too small or
limited; we don't want requirements that are weak from either cause.
 
Comment 2-3:

I changed "lost" in rendering to "ignored" in rendering when referring to
style information.

Comment 2-4:

I changed the second to the last paragraph to make clear that the notion of
"pre-rendering content" applies to both text elements and non-text elements,
not just text equivalents. This is a fairly important fix.


===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090

Received on Thursday, 19 October 2000 18:22:01 UTC