Minor revisions to 'Equivalent' and 'Text content'

Following are what I believe are minor revisions to 'Equivalent' and 'Text
content'.

Suggestion 1: Revise the definition of Equivalent.

Old (19 October 2000 revision):

> <<**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_.**>>

New:

> <<**Equivalents include text equivalents, (e.g., <<DELETED "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_.**>>

Comment 1:

The reason for this change is that I would rather not get boxed in or have
others be boxed in as to whether long or short text equivalents are distinct
text equivalents or that they are part of the same text equivalent). 

Suggestion 2: Revise the definition of 'Text content'.

This version reflects the changes suggested yesterday plus adds a few more.
Not every single change is annotated as such.

New:

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

In this document, the term "text element" refers to content that is
understandable in each of three specific modes when presented to their
respective reference disability group:

1. visually-displayed text, for users who are deaf and adept in reading
visually-displayed text; 
2. synthesized speech, for users who are blind and adept in use of
synthesized speech; 
3. braille, for users who are deaf-blind and adept at reading braille. 

In these definitions, the content is said to be "understandable" when it
fulfills its essential communication function (see the definition of
Equivalent). Furthermore, these definitions make assumptions such as the
availability of appropriate hardware and software, that content represents a
general mix of purposes (information, education, entertainment, commerce),
that the individuals in the groups are able to understand the natural
language of the content but that they are not experts in computer science,
etc.

A text element may contain markup for style (e.g., font size or color),
structure (e.g., heading levels), and other semantics. 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 groups. Thus, a
text element has important accessibility advantages often associated with
"text" while a non-text element lacks one or more such advantages.

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).

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 element 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
equivalent).



====

Some of the latest changes to "Equivalent" are as follows:

Comment 1:

I used the term "reference" more often than it appeared in the last
revision. 

Comment 2:

I made reference to semantics in discussing markup and reordered the kinds
of markup.

Comment 3: 

In the paragraph that includes "in principle", the example is corrected to
refer to "text element" rather that "text equivalent".

Comment 4:

I added the comment about mix of purposes. I think that mentioning this is
important because we are not talking about just one narrow kind of
information purpose.

Comment 5:

To keep this material in perspective, I would like our definitions to be
flexible enough and  precise enough so that if we ever prescribed some other
kind of equivalent, such as a 'picture equivalents' for certain kinds of
non-picture content or 'sign language video equivalents' for certain kinds
of non-sign-language elements, that the system would allow those
requirements to be added. In saying this, I am not necessarily advocating
that we do these things now. I just would like the framework to be robust
and flexible.

> -----Original Message-----
> From: Hansen, Eric [mailto:ehansen@ets.org]
> Sent: Thursday, October 19, 2000 6:21 PM
> To: Ian Jacobs (E-mail); UA List (E-mail); Jon Gunderson (E-mail)
> Subject: 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 Friday, 20 October 2000 15:59:49 UTC