- From: <ehansen@ets.org>
- Date: Wed, 17 Nov 1999 17:23:13 -0500 (EST)
- To: w3c-wai-ua@w3.org
(This is Part 2)
Issue #16. Eliminate the use of "continuous equivalent track".
To the best of my knowledge, this is a new term that is not necessary.
Unless someone can point out why it is necessary, then I suggest that it be
removed. It is used in very few locations.
I will point out just a few of the problems in the definition of
"continuous equivalent track".
The old version reads:
"Continuous Equivalent Track"
"A continuous equivalent track presents an equivalent alternative to
another track (generally audio or video) and is synchronized with that
track. Continuous equivalent tracks convey information about spoken words
and non-spoken sounds such as sound effects. A continuous text track
presents closed captions. Captions are generally rendered visually by being
superimposed over a video track, which benefits people who are deaf and
hard-of-hearing, and anyone who cannot hear the audio (e.g., when in a
crowded room). A collated text transcript combines (collates) captions with
text descriptions of video information (descriptions of the actions, body
language, graphics, and scene changes of the video track). These text
equivalents make presentations accessible to people who are deaf-blind and
to people who cannot play movies, animations, etc."
"One example of a non-text continuous equivalent track 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."
"A video track that shows sign language is another example of a continuous
equivalent track."
Some of the problems:
a. One of the biggest problems is that the reference to collated text
transcripts is totally out of place because it is not a "continuous
equivalent track."
b. The above definition cites auditory description as an example of
"non-text continuous equivalent track". Yet in this context, "non-text"
seems misleading because it could be derived ("on the fly") from text.
c. A "video track that shows sign language" is cited as an example of a
continuous equivalent track, but it is not necessarily "equivalent" to
anything (except itself) since it could be part of the "primary" content.
It needs to be cited as equivalent of (or to or for) something else. Unless
we want to nudge WCAG to requiring non-text equivalents (other than
auditory descriptions), then I suggest removing reference to "video of sign
language" in checkpoint 2.5. The Priority 1 rating of this implies that it
must be done, yet there is no WCAG requirement for non-text equivalents for
"primary content". The checkpoints themselves should only mention what we
are asserting is required.
d. It uses the term "text equivalents" which has not be defined in this
document.
I recommend that we use a term such as "synchronized alternatives" or
"synchronized alternative tracks", both of which are similar to WCAG
checkpoint 1.4, which reads: "For any time-based multimedia presentation
(e.g., a movie or animation), synchronize equivalent alternatives (e.g.,
captions or auditory descriptions of the visual track) with the
presentation. [Priority 1]". As the WCAG archives show, this wasn't my
favorite term since it seemed redundant. Yet I am against coining totally
new terms unless there is a need. (Note that for good or ill, this term is
similar to the following UAAG checkpoint: "5.7 Provide programmatic
exchange of information in a timely manner. [Priority 2] This is important
for synchronous alternative renderings and simulation of events". This last
sentence seems vague to me and may benefit fine-tuning to make it fit with
the revised usage. By the way, the checkpoint statement for 5.7 also seems
vague. I would think more explanation is needed.)
The deletion of "continuous equivalent track" affects checkpoint 2.5 and
the glossary. I recommend modifying checkpoint 2.5 (see below) and deleting
the glossary definition.
----
Issue #17. Simplify checkpoint 2.5.
Old:
"2.5 Allow the user to specify that continuous equivalent tracks (e.g.,
closed captions, auditory descriptions, video of sign language, etc.) be
rendered at the same time as audio and video tracks. [Priority 1]"
"Techniques for checkpoint 2.5"
New checkpoint 2.5:
"2.5. Ensure that any synchronized alternative (e.g., caption, auditory
description) can be presented at the same time as the relevant audio and
video tracks . [Priority 1]"
"Note. _Captions_ are synchronized with the video and audio tracks to
benefit users who are deaf or hard of hearing. _Auditory descriptions_ are
synchronized with the video track to benefit users who have visual
disabilities or certain learning disabilities. See definition of
_equivalents_" {NEED TO ADD DEFINITION OF EQUIVALENT}
"Techniques for checkpoint 2.5"
Notes on changes:
The old version of checkpoint 2.5 seemed to imply that providing
synchronization takes place as some kind of special request ("specify").
However, I would expect synchronization to occur as default behavior. My
new version softens that implication.
Note that these changed versions make no reference to sign language videos.
As noted earlier, the reference to "video of sign language" in checkpoint
2.5 seem very inappropriate since WCAG does not require it. The Priority 1
rating of this implies that it must be done. The checkpoints themselves
should only mention what we are asserting is required. It could be put in a
note, if necessary.
----
Issue #18. Handle "on the fly" auditory descriptions.
Old: N/A
New checkpoint 2.5.A:
"2.5.A. Within one year from time that the W3C provides a specification for
generating auditory descriptions from a text equivalent of video track,
provide a capability conforming to that specification." [Priority 2]
"Techniques for checkpoint 2.5.A"
Notes on changes:
WCAG requires auditory descriptions for movies and mentions that they may
consist of prerecorded audio or be generated "on the fly". The content
author is required to provide auditory descriptions. That currently that
means prerecorded audio, but the high cost of providing prerecorded
auditory descriptions, as well as the flexibility of synthesized speech
will make the synthesized-speech auditory descriptions attractive.
The specific mechanics for implementing synthetic-speech auditory
descriptions have yet to be worked out, but user agents should be required
to render them when a spec is produced. The text for synthetic-speech
auditory descriptions could conceivably come directly from the collated
text transcript but the latter does not currently have synchronization
information so that would need to be added. I don't know how the SMIL spec
figures into all of this. Important note: Because one cannot always say
everything in "natural pauses" in dialogue, the capability for generating
auditory descriptions must have a capability for pausing the visual track
to allow long auditory descriptions to be spoken.
Incidentally, I think that a Web content developer that provides the text
content for producing auditory descriptions on the fly should not be
required to provide the prerecorded auditory descriptions. This needs to be
made explicit in WCAG.
----
Issue #19. The UAAG document cannot be imported into MS Word 97 SR-1.
It seems to me that a while ago I didn't have trouble importing the WAI
guideline documents into MS Word 97. Now the opening of the file fails and
there an indication that the file is corrupted. Can anyone tell me how to
overcome this problem?
----
Issue #20. Add the definition of "Equivalent"
The term is used but is undefined. The term needs to be defined and
examined in its usage in the document.
I suggest something along the lines of the definition in WCAG or
corresponding definitions in ATAG.
----
Issue #21. Refine definition of "text transcript."
This definition needs to be clarified and corrected. I think that the
reference to "continuous equivalent track" is erroneous and misleading
because a text transcript, as currently defined, does not include
synchronization information in the sense that captions do.
Old:
"Text transcript"
"A text transcript is a text equivalent of audio information that includes
spoken words and non-spoken sounds such as sound effects. Refer also to
continuous equivalent track."
New:
"Text transcript"
"In the context of this document, a text transcript is a text equivalent of
an audio information (e.g., audio clip). It provides text for both speech
and non-speech sounds."
----
Issue #22. Consider the possible use of "visual track" and "auditory
track".
We used the terms "visual track" and "auditory track" in WCAG because it
covered animations as well. Is there a reason why these terms are not used
in UAAG?
----
Issue #23. Reconsider the inconsistency in the possible use of the term
"alternative text".
The definition of alternative text seems problematic. In WCAG we avoided
using the term and for good reason I think. An example of the problem is
found in the definition of "Documents, Elements, and Attributes". It says
"Alternative representations may take a variety of forms including
alternative text, closed captions, and auditory descriptions." It should
read, I think something like: "Alternative representations include text
equivalents (long and short, synchronized and unsynchronized) and non-text
equivalents (prerecorded auditory descriptions)."
If the term "alternative text" is to be used, then it should be defined in
the glossary.
----
Issue #24. Fix the definition of "user agent" in the glossary.
See the first issue in this document.
----
Issue #25. Deemphasize security issue in checkpoint 3.7. This benefit must
be clearly delineated from the rationale for doing it. The rationale must
be disability-related.
Old:
"3.7 Allow the user to turn on and off support for scripts and applets.
[Priority 1]"
"Note. This is particularly important for scripts that cause the screen to
flicker, since people with photosensitive epilepsy can have seizures
triggered by flickering or flashing in the 4 to 59 flashes per second
(Hertz) range. Users should be able, for security reasons, to prevent
scripts from executing on their machines."
New:
"3.7 Allow the user to turn on and off support for scripts and applets.
[Priority 1]"
"Note. This is particularly important for scripts that cause the screen to
flicker, since people with photosensitive epilepsy can have seizures
triggered by flickering or flashing in the 4 to 59 flashes per second
(Hertz) range. (A benefit of allowing users to prevent scripts from
executing on their machines is improved security against harmful scripts.)"
----
Issue #26. Fix undefined reference to "audio closed captions".
Also does this mean control it separate from the video? What if both can be
relocated together?
Old:
"4.9 Allow the user to control the position of audio closed captions.
[Priority 1]"
New:
"4.9 Allow the user to control the position of captions. [Priority 1]"
----
Issue #27. Fix expanded statement for guideline 4.
Shouldn't it refer to author-specified styles?
Old:
"Guideline 4. Ensure user control over styles"
"Ensure that the user has control over the colors, text size, speech rate
and pitch, and other stylistic aspects of a resource and can override
author styles and user agent default styles."
New:
"Guideline 4. Ensure user control over styles"
"Ensure that the user has control over the colors, text size, speech rate
and pitch, and other stylistic aspects of a resource and can override
author-SPECIFIED styles and user agent default styles."
----
Issue #28. Fix reference to "show = 'new'".
Shouldn't the command "show = 'new'" be highlighted or emphasized in some
way?
"4.18 Allow the user to control user agent-initiated spawned viewports.
[Priority 2]
For example, in HTML, allow the user to control the process of opening a
document in a new target frame or a viewport created by author-supplied
scripts. In SMIL 1.0, allow the user to control viewports created with
show="new". Control may involve prompting the user to confirm or cancel the
viewport creation. Users may also want to control the size or position of
the viewport and to be able to close the viewport (e.g., with the "back"
functionality)."
----
Issue #29. Fix first portion of the Introduction.
The first portion of the Introduction tends to confuse the definition of
"accessibility". In the context of these WAI guidelines documents,
accessibility focuses on people with disabilities. Benefits for small
screens, slow Internet connections, noisy environments,
internationalization, computer security, etc., are valuable side benefits
of "accessible design", but they are not the reasons for the documents. The
introduction seems to imply that "accessibility" means making Web
information available to people in all these different contexts. I think
that it is fine to talk about the benefits of accessible design, but in my
opinion one should carefully distinguish between the rationale for
accessible design (requirements of people with disabilities) and its
benefits (improved usability, interoperability, etc.).
Old:
{start of Old}
1. Introduction
For those unfamiliar with accessibility issues pertaining to user agent
design, consider that many users may be accessing the Web in contexts very
different from your own:
(bullet) They may not be able to see, hear, move, or may not be able to
process some types of information easily or at all.
(bullet) They may have difficulty reading or comprehending text.
(bullet) They may not have or be able to use a keyboard or mouse.
(bullet) They may have a text-only screen, a small screen, or a slow
Internet connection.
(bullet) They may not speak or understand fluently the language in which
content is written or spoken.
(bullet) They may be in a situation where their eyes, ears, or hands are
busy or interfered with (e.g., driving to work, working in a loud
environment, etc.).
User agents must be designed to take into account the diverse functional
requirements of users with disabilities. Software that follows the
guidelines in this document will not only benefit users with disabilities,
it will be more flexible, manageable, and extensible. The guidelines have
been chosen according to some basic principles of accessible design,
presented below.
1.1 Principles of Accessible Design
This document is organized according to several principles that will
improve the design of any type of user agent:
{end of Old}
New:
{start of New}
1. Introduction
{Here is a possible beginning of an introduction.}
This Introduction (part 1) lays essential groundwork for understanding the
guidelines themselves (part 2). The Introduction has seven sections.
1. Introduction
1.1 Benefits of Accessible Design {or some other title} {NEW} {short
explanation}
1.2 Principles of Accessible Design {short explanation}
1.3 How the Guidelines are Organized {short explanation}
1.4 Related Documents {short explanation}
1.5 Document conventions {short explanation}
1.6 Priorities {short explanation}
1.7 Conformance {short explanation}
1.1 Benefits of Accessible Design {or Benefits of Following the Guidelines,
etc.}
[etc.]
1.2 Principles of Accessible Design
FOLLOWING ARE several principles that will improve the design of any type
of user agent:
{end of New}
----
Issue #30. Fix checkpoint 11.1.
a. Make it a Relative Priority.
b. Avoid the phrase "as per". To the best of my knowledge it is a redundant
phrase and "per" by itself is correct. (Nevertheless, the phrase is
probably used incorrectly more often than correctly.)
c. Don't use "[WAI-WEBCONTENT]" as document name.
Old:
"11.1 Provide a version of the product documentation that conforms to the
Web Content Accessibility Guidelines. [Priority 1]"
"User agents may provide documentation in many formats, but one must be
accessible as per [WAI-WEBCONTENT]. Alternative content, navigation
mechanisms, and illustrations will all help make the documentation
accessible."
New:
"11.1 Provide a version of the product documentation that conforms to the
Web Content Accessibility Guidelines. [Priority 1]"
"User agents may provide documentation in many formats, but one must be
accessible PER THE WEB CONTENT ACCESSIBILITY GUIDELINES [WAI-WEBCONTENT].
Alternative content, navigation mechanisms, and illustrations will all help
make the documentation accessible."
----
Issue #31. Consider new terms associated with "Views", "Viewports", etc.
There is a large cluster of terms that are new to this document and I am
not sure that they are consistent and parsimonious. Some of these terms
are:
views
viewports
point of regard
cursor
focus
focus information
selection
selection information
focus mechanisms
selection mechanisms
highlighted selection
highlighted focus
focus content
focus selection
current viewport
current selection
current focus
focused link
focus position
highlighting
----
Issue #32. Clarify explanation of "point of regard".
The definition of point of regard seems strange:
"The content currently available in the viewport is called the user's point
of regard. The point of regard may be a two dimensional area (e.g., for
graphical rendering) or a single point (e.g., for aural rendering or voice
browsing). User agents should not change the point of regard unexpectedly
as this can disorient users."
It seems unusual, within the same paragraph to describe "point of regard as
"content", a "two dimensional area" (should be hyphenated), and a "single
point."
----
Issue #33. Expand acronyms.
Expand acronyms at least the first time that they occur in the document.
Some should be expanded more than once.
----
Issue #34. Reconsider the use of the term "functionalities".
I am not sure why the word functionality is used instead of function. If
they mean the same thing, I would think that the latter would be simpler
and better.
----
Issue #35. Reconsider the use of the term "table caption".
The term "table caption", which is found in checkpoint 2.5, is undefined.
Could be confused with "caption" as otherwise used in WAI docs. I would
suggest avoiding the word caption if possible. How does it relate to WCAG?
----
Issue #36. Reconsider the use of the term "motor disability".
I think that "physical disability" is more standard.
----
Issue #37. Reconsider the use of the term "visual impairment".
In our organization, the term is considered insensitive (unfair). Use
"visual disability". The preferred terms can change, but keeping up with
the preferred terms is important.
----
Issue #38. Put "Braille" in lowercase.
I think our WAI convention is to lowercase it.
----
Issue #39. Reconsider the contrast between "braille and haptic".
Is braille also haptic? This may be OK as is. See "Definition of "Documents,
Elements, and Attributes"
----
Issue 40: Document uses the terms "impairment(s)".
Should be "disability" or "disabilities."
----
Issue 41: Document has at least one spelling problem.
Run the speller. See the word "keystoke" [sic].
----
Issue #42. Link names are improperly used in sentences.
Avoid using cryptic document link names (e.g., "[HTML40]") as though they
were plain English words. An example of what not to do is: "10.2 Provide
information about the current author-specified input configuration (e.g.,
keyboard bindings specified in content such as by "accesskey" in [HTML40]".
Another example involves the phrase "in [DOM1]". Document names should be
expanded out somewhat: "10.2 Provide information about the current
author-specified input configuration (e.g., keyboard bindings specified in
content such as by "accesskey" in HTML 4.0 [HTML40]" This is particularly
important in important sentences like checkpoint sentences.
----
Issue #43. Fix the definition of "Documents, Elements, and Attributes"
This definition needs fixing. See below.
Old:
"Documents, Elements, and Attributes. A document may be seen as a hierarchy
of elements. Elements are defined by a language specification (e.g., HTML
4.0 or an XML application). Each element may have content, which generally
contributes to the document's content. Elements may also have attributes
that take values. An element's rendered content is that which a user agent
renders for the element. This may be what lies between the element's start
and end tags, the value of an attribute (c.f. the "alt", "title", and
"longdesc" attributes in HTML), or external data (e.g., the IMG element in
HTML). Rendering is not limited to graphical displays alone, but also
includes audio (speech and sound) and tactile displays (braille and haptic
displays). Since rendered content is not always accessible, authors must
specify alternative equivalents for content that user agents must make
available to users or software that require it (in place of and/or in
addition to the "primary" content). Alternative representations may take a
variety of forms including alternative text, closed captions, and auditory
descriptions. The Techniques Document ([UA-TECHNIQUES]) describes the
different mechanisms authors use to supply alternative representations of
content. Please also consult the Web Content Accessibility Guidelines
([WAI-WEBCONTENT] and ([WAI-WEBCONTENT-TECHS]."
New:
"Documents, Elements, and Attributes. A document may be seen as a hierarchy
of elements. Elements are defined by a language specification (e.g., HTML
4.0 or an XML application). Each element may have content, which generally
contributes to the document's content. Elements may also have attributes
that take values. An element's rendered content is that which a user agent
renders for the element. This may be what lies between the element's start
and end tags, the value of an attribute (c.f. the "alt", "title", and
"longdesc" attributes in HTML), or external data (e.g., the IMG element in
HTML). Rendering is not limited to graphical displays alone, but also
includes AUDITORY (SPEECH AND NON-SPEECH SOUNDS) and tactile displays
(braille and haptic displays). Since rendered content is not always
accessible, authors must specify alternative equivalents for content that
user agents must make available to users or software that require it (in
place of and/or in addition to the "primary" content). ALTERNATIVE
REPRESENTATIONS INCLUDE TEXT EQUIVALENTS (LONG AND SHORT, SYNCHRONIZED AND
UNSYNCHRONIZED) AND NON-TEXT EQUIVALENTS (PRERECORDED AUDITORY
DESCRIPTIONS). The Techniques Document ([UA-TECHNIQUES]) describes the
different mechanisms authors use to supply alternative representations of
content. Please also consult the Web Content Accessibility Guidelines
([WAI-WEBCONTENT] and ([WAI-WEBCONTENT-TECHS]."
----
=============================
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 Wednesday, 17 November 1999 17:33:14 UTC