W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 1999

Issues

From: <ehansen@ets.org>
Date: Thu, 28 Oct 1999 18:09:52 -0400 (EDT)
To: w3c-wai-au@w3.org
Message-id: <vines.Bh0E+kaA4sA@cips06.ets.org>
Following are several issues that should be addressed in the 26 October 
version of ATAG 1.0.

Issue #1: Checkpoint 3.3 has several problems.

a. The checkpoint uses the term "video captions", which is undefined. Per 
an earlier memo: "The term "video captions" is extremely likely to be 
confused with the terms "video description" or "descriptive video" which is 
WGBH/NCAM's name for auditory description." 
(http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/0102.html, 
problem #4). Furthermore, some people will wonder, "I've heard of open 
captions and closed captions, but what are video captions?" The term "video 
captions" will confuse many.
b. The checkpoint uses the term "synchronized text", which is undefined.
c. The term "audio equivalent" is imprecise and not defined elsewhere. Use 
the term "auditory description."
d. The checkpoint and the document in often uses the string 
"[WAI-WEBCONTENT]" as a replacement for the term "W3C Web Content 
Accessibility Guidelines" or for the acronym "WCAG". ("3.3 Ensure that 
prepackaged content conforms to [WAI-WEBCONTENT].") This manner of using a 
special string instead of plain English was rarely used in the WCAG 1.0 
document but is used frequently in ATAG 1.0. Is this is a new and accepted 
W3C or Internet convention? Shouldn't the document, especially the 
checkpoint statements themselves be written, as much as possible, in plain 
English? The ATAG document also uses the other method: "Some checkpoints 
that refer to generating, authoring, or checking Web content have multiple 
priorities. The priority is dependent on the priority in the Web Content 
Accessibility Guidelines [WAI-WEBCONTENT]." But that correct (?!) usage now 
seems rarer. I urge correcting this problem, especially in checkpoint 
statements and other material likely to be lifted into other contexts.

OLD:

3.3 Ensure that prepackaged content conforms to [WAI-WEBCONTENT]. [Relative 
Priority] 
For example include synchronized text and audio equivalents (such as video 
captions) with movies. Refer also to checkpoint 3.4. 

PREVIOUSLY SUGGESTED 
(http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/0102.html)

"3.3 Ensure that prepackaged content conforms to [WAI-WEBCONTENT]. 
[Relative Priority] "

"For example, for movies include captions, auditory descriptions, and 
collated text transcripts. Refer also to checkpoint 3.4."

NEW:

3.3 Ensure that prepackaged content conforms to the Web Content 
Accessibility Guidelines [WAI-WEBCONTENT]. [Relative Priority] 

"For example, for movies include captions, auditory descriptions, and 
collated text transcripts. Refer also to checkpoint 3.4."

====
Issue #2: Intro to guideline 3 needs a few edits. The NEW version shows 
changed areas in ALLCAPS. For a more extensive revision see problem #6 in 
http://lists.w3.org/Archives/Public/w3c-wai-au/1999OctDec/0102.html.

OLD:
Guideline 3. Support the creation of accessible content
Well structured information, and equivalent alternative information are 
cornerstones of accessible design, allowing information to be presented in 
a way most appropriate for the needs of the user without constraining the 
creativity of the author. Yet generating equivalent information, such as 
textual alternatives for images and audio descriptions of video, can be one 
of the most challenging aspects of Web design, and authoring tool 
developers should attempt to facilitate and automate the mechanics of this 
process. For example, prompting authors to include equivalent alternative 
information such as text equivalents, captions, and auditory descriptions 
at appropriate times can greatly ease the burden for authors. Where such 
information can be mechanically determined and offered as a choice for the 
author (e.g., the function of icons in an automatically-generated 
navigation bar, or expansion of acronyms from a dictionary) the tool can 
assist the author. At the same time it can reinforce the need for such 
information and the author's role in ensuring that it is used appropriately 
in each instance.

NEW:

Guideline 3. Support the creation of accessible content
WELL-STRUCTURED information, and equivalent alternative information are 
cornerstones of accessible design, allowing information to be presented in 
a way most appropriate for the needs of the user without constraining the 
creativity of the author. Yet generating equivalent information, such as 
textual alternatives for images and AUDITORY descriptions FOR MOVIES, can 
be one of the most challenging aspects of Web design, and authoring tool 
developers should attempt to facilitate and automate the mechanics of this 
process. For example, prompting authors to include equivalent alternative 
information such as text equivalents, captions, and auditory descriptions 
at appropriate times can greatly ease the burden for authors. Where such 
information can be mechanically determined and offered as a choice for the 
author (e.g., the function of icons in an automatically-generated 
navigation bar, or expansion of acronyms from a dictionary) the tool can 
assist the author. At the same time it can reinforce the need for such 
information and the author's role in ensuring that it is used appropriately 
in each instance.
 
Issue #3: Checkpoint 3.1 needs clarification. The term "movie clips" or 
"movie" should be used instead of "video" to avoid confusion with "video 
track".

OLD:

3.1 Prompt the author to provide equivalent alternative information (e.g., 
captions, auditory descriptions and collated text transcripts for video). 

NEW:

3.1 Prompt the author to provide equivalent alternative information (e.g., 
captions, auditory descriptions, {Note the comma} and collated text 
transcripts for movie clips). {or "movies"} 

====
Issue #4: The definition of "accessibility" has several problems. 

a. The definition is ambiguously phrased. It could mean:

1 - (accessible Web content AND accessible authoring tool) mean (content 
AND tool can be used)
OR
2 - (accessible Web content means content can be used) AND (accessible 
authoring tool means tool can be used)

The 2nd meaning is the one that should be conveyed. (By the way, the same 
phrasing issue is found in the definition for Accessibility Problem, but is 
not so serious in that context.)

b. The main entry word "Accessibility" is not used in the first sentence of 
the definition. The entry word and the definition should match.

c. The reference to use by "people regardless of disability" is a standard 
that is unnecessarily strict. I think that we are trying to convey a fairly 
commonsense definition of "accessible." The definition should not be so 
specific or extreme. No useful purpose is served by having it so extreme. 
(By the way, as I believe I have noted earlier, I also find the phrase 
"regardless of disability" problematic in the first sentence of the 
introduction. I think that one can readily argue that there are some 
disabilities for which Web documents _cannot_ be made accessible through 
compliance to the current ATAG and WCAG documents. The problem in the first 
sentence of the introduction is not as severe as the problem in the 
definition of "accessible".)

OLD:
Accessibility (Also: Accessible) 
Within these guidelines, "accessible Web content" and "accessible authoring 
tool" mean that the content and tool can be used by people regardless of 
disability. 
[etc.]

NEW:

Accessible 
Within these guidelines, something that is accessible is usable by people 
with disabilities. For example, an "accessible authoring tool" is an 
authoring tool that is usable by people with disabilities and "accessible 
content" is content that is usable by people with disabilities. Authoring 
tools that conform to these guidelines will both (1) be accessible and (2) 
enable and encourage the generation of accessible content.{I can't help 
liking this last sentence. I think something like it should be present in 
the early part of the document.}
[etc.]
====
Issue #5: The definition of Alternative Information has a couple of 
problems. 

a. It improperly softens the requirement. It says that "Authors are 
encouraged to provide text equivalents for non-text content." Yet providing 
such text equivalents is an essential requirement.
b. It uses the ambiguous phrase "graphical text". This phrase will suggest 
to people the idea of a graphic, i.e., an image. A better, more general, 
phrase is "visually-displayed text."

Changes are noted below in ALLCAPS.

OLD:

Alternative Information (Also: Equivalent Alternative) 
Content is "equivalent" to other content when both fulfill essentially the 
same function or purpose upon presentation to the user. Equivalent 
alternatives play an important role in accessible authoring practices since 
certain types of content may not be accessible to all users (e.g., video, 
images, audio, etc.). Authors are encouraged to provide text equivalents 
for non-text content since text may be rendered as synthesized speech for 
individuals who have visual or learning disabilities, as braille for 
individuals who are blind, or as graphical text for individuals who are 
deaf or do not have a disability. For more information about equivalent 
alternatives, please refer to [WAI-WEBCONTENT]. 

NEW VERSION 1:

Alternative Information (Also: Equivalent Alternative) 
Content is "equivalent" to other content when both fulfill essentially the 
same function or purpose upon presentation to the user. Equivalent 
alternatives play an important role in accessible authoring practices since 
certain types of content may not be accessible to all users (e.g., video, 
images, audio, etc.). Authors MUST provide text equivalents for non-text 
content since text may be rendered as synthesized speech for individuals 
who have visual or learning disabilities, as braille for individuals who 
are blind, or as VISUALLY-DISPLAYED text for individuals who are deaf or do 
not have a disability. For more information about equivalent alternatives, 
please refer to [WAI-WEBCONTENT].

NEW VERSION 2:

Alternative Information (Also: Equivalent Alternative) 
Content is "equivalent" to other content when both fulfill essentially the 
same function or purpose upon presentation to the user. Equivalent 
alternatives play an important role in accessible authoring practices since 
certain types of content may not be accessible to all users (e.g., video, 
images, audio, etc.). TEXT EQUIVALENTS MUST BE PROVIDED FOR ALL NON-TEXT 
CONTENT SINCE TEXT MAY FLEXIBLY BE RENDERED as synthesized speech for 
individuals who have visual or learning disabilities, as braille for 
individuals who are blind, or as VISUALLY-DISPLAYED text for individuals 
who are deaf or do not have a disability. For more information about 
equivalent alternatives, please refer to [WAI-WEBCONTENT].
====

Issue #6: The definition of auditory description needs clarification.

a. The fact that an auditory description is an auditory _equivalent_ of a 
visual track must be emphasized.
b. The reference to "low-bandwidth" in definition of the auditory 
description was vague and needs clarification. For example, it should be 
made clear that auditory descriptions must be integrated with the regular 
audio track order to have an auditory equivalent of the movie. 
c. The current definition of auditory description must be modified to note 
that an auditory description "is" synchronized with the regular audio, per 
WCAG 1.0. 

OLD:
Auditory Description 
An auditory description provides information about actions, body language, 
graphics, and scene changes in a video. They are commonly used by people 
who are blind or have low vision, although they may also be used as a 
low-bandwidth equivalent on the Web. An auditory description is either a 
pre-recorded human voice or a synthesized voice (recorded or generated on 
the fly). The auditory description must be synchronized with the audio 
track of a video presentation, usually during natural pauses in the audio 
track. 

NEW:

Auditory Description 
An auditory description is an auditory equivalent of the visual track of a 
movie (or other multimedia presentation). The auditory description is 
synchronized with the audio track, usually during natural pauses (e.g., 
gaps in the spoken dialogue). Auditory descriptions are particularly 
helpful for people who are blind or have low vision. The audio is provided 
by either a pre-recorded human voice or a synthesized voice (recorded or 
generated on the fly). Auditory descriptions must convey all essential 
visual information, e.g., actions, body language, graphics, scene changes. 
Users limited to low-bandwidth Web access may find auditory descriptions 
(integrated with the regular audio track) a useful low-bandwidth 
alternative to high-bandwidth movies. 

FOR COMPARISON -- WCAG 1.0:

One example of a non-text equivalent is an auditory description of the key 
visual elements of a presentation. The description is either a prerecorded 
human voice or a synthesized voice (recorded or generated on the fly). The 
auditory description is synchronized with the audio track of the 
presentation, usually during natural pauses in the audio track. Auditory 
descriptions include information about actions, body language, graphics, 
and scene changes. 

====
Issue #7: The definition of "captions" should avoid the word "graphically". 
As suggested earlier, terms like "graphically", or "graphical", and 
"graphic" suggest the idea of a graphic, e.g., a "gif" file. A better 
phrase is "visually-displayed text."


OLD

Captions 
Captions are essential text equivalents for movie audio. Captions consist 
of a text transcript of the audio track of the movie (or other video 
presentation) that is synchronized with the video and audio tracks. 
Captions are generally rendered graphically and benefit people who can see 
but are deaf, hard-of-hearing, or cannot hear the audio. 

Captions 
Captions are essential text equivalents for movie audio. Captions consist 
of a text transcript of the audio track of the movie (or other video 
presentation) that is synchronized with the video and audio tracks. 
Captions are generally DISPLAYED VISUALLY and benefit people who can see 
but are deaf, hard-of-hearing, or cannot hear the audio. 
====
Issue #7: A paragraph in the intro has several problems.

a. Reference to "similar needs" is insensitive. I may be wrong, but I think 
that our corporate sensitivity review process would mandate a change to 
this. The problem is that it reinforces the stereotype of people with 
disabilities as being "needy". 
b. The reference to "people who do not have a physical disability" is, I 
believe, incorrect. The term "physical disability" generally refers to a 
major class of disability like other major classes (cognitive disability, 
visual disability, learning disability, emotional disability, hearing 
disability, etc.). Thus the set of people without a physical disability 
might include many people with visual, hearing, cognitive, or other 
disabilities. Yet the apparent intent of the phrase is to refer to "people 
without any disability". This needs to be corrected.
c. I don't think that the phrase "people who do not have a physical 
disability but with similar needs" is grammatical. Grammar is not my strong 
suit, so verify with others.

OLD: 

In addition, accessible design will benefit many people who do not have a 
physical disability but with similar needs. For example they may be working 
in a noisy environment and unable to hear, or need to use their eyes for 
another task, and be unable to view a screen. They may be using a small 
mobile device, with a small screen, no keyboard and no mouse.

NEW:

In addition, accessible design will benefit many people who have no 
disability but are operating under various environmental or technological 
constraints. For example they may be working in a noisy environment and 
unable to hear, or need to use their eyes for another task, and be unable 
to view a screen. Or they may be using a small mobile device, with a small 
screen, no keyboard and no mouse.


=============================
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 Thursday, 28 October 1999 18:15:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:56 GMT