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

Issues: Part 2 - #16 through #43

From: <ehansen@ets.org>
Date: Wed, 17 Nov 1999 17:23:13 -0500 (EST)
To: w3c-wai-ua@w3.org
Message-id: <vines.Bh0E+FfmAsA@cips06.ets.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT