- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 23 Nov 1999 17:53:44 -0500
- To: ehansen@ets.org
- CC: w3c-wai-ua@w3.org
ehansen@ets.org wrote:
>
> (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.
We started using "continuous equivalent" in the SMIL access note [1].
We distinguish there between discrete equivalent (like "alt") and
one that must be synchronized with another track.
[1] http://www.w3.org/TR/SMIL-access/
> 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."
Agreed. Could be deleted.
> 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.
But derived from text is an implementation detail. The end product
must be audio.
> 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.
I don't agree. I think that the text clearly states that this is
an example of a continuous equivalent track.
> d. It uses the term "text equivalents" which has not be defined in this
> document.
Hmm, you're right! I thought it was for sure.
> 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]".
I have no objection to synchronized equivalent. Is there any
reason why a continuous equivalent would not be synchronized?
> 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.
Yes.
> By the way, the checkpoint statement for 5.7 also seems
> vague. I would think more explanation is needed.)
The goal: assistive technologies, to function, must have timely access
to information. Thus, for example, it should be possible to load
them into the process space of the user agent to minimize communication
times.
> 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]"
Ok by me. I still don't think it's necessary to delete the sign language
example.
> "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.
That's also an ok solution for me.
> ----
> 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"
Even before reading the notes, I see where you're going: WCAG 1.3 is
an "until user agents" and we don't have a matching checkpoint.
> 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.
I'll forward that to the wcag list
_ Ian
> ----
> 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?
Are you importing the HTML? I'd be curious to know how to fix this
so we don't get lots of complaints after publication. (We've had
problems with people printing the PDF of WCAG, for example, and I'd
like to solve that one too).
> ----
> 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.
Yes.
> ----
> 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."
Why only "in the context of this document"? How about:
"A text transcript is a text equivalent of auditory information (e.g.,
an
audio clip). A text transcript documetns both speech and non-spoken
sounds such as sound effects."
> ----
> 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?
We do use it in some places: Checkpoint 1.1, 1.3, defn of Equivalent.
Where would you use it?
> ----
> 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.
I think we can harmonize with WCAG.
> ----
> 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.)"
I don't agree with parens, but we can de-emphasize with language.
> ----
> 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]"
Depends on outcome of "closed captions" v. "captions" discussion.
> ----
> 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."
Yes.
> ----
> 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)."
How about <code>?
> ----
> 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}
> ----
Eric, I would prefer to keep the "some users may be in different
scenarios than yours" bit, although we might say that not all
issues relate to accessibility; there could be clarification.
I'll have to think about the rest of the proposed text/structure.
> Issue #30. Fix checkpoint 11.1.
>
> a. Make it a Relative Priority.
Will discuss in WG.
> 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.)
I didn't know that! Thanks
> 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
Argh. I guess a severely close look is required.
> ----
> 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.
Most of them should be expanded. But I'll review.
> ----
> 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.
I don't think they mean the same thing. "functionality" means "feature".
"Function" means "purpose" (to me).
> ----
> 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?
I think "table caption" is acceptable and that's why we say
"closed captions" elsewhere.
> ----
> Issue #36. Reconsider the use of the term "motor disability".
>
> I think that "physical disability" is more standard.
Ok.
> ----
> 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.
Should we drop "impairment" everywhere?
> ----
> Issue #38. Put "Braille" in lowercase.
>
> I think our WAI convention is to lowercase it.
There's been discussion about it on the list and there's
no clear consensus about which way it should go. For consistency
with WCAG, yes to lowercase.
> ----
> 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."
Ok, see point 37 above.
> ----
> Issue 41: Document has at least one spelling problem.
>
> Run the speller. See the word "keystoke" [sic].
Fixed.
> ----
> 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.
Yes. This is done inconsistenly in the document.
> ----
> 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]."
> ----
Thank you Eric!
- Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Tuesday, 23 November 1999 17:53:31 UTC