Re: Proposal for issue 321: (language diversity - is choice required?)

Al,
I think what languages of the equivalents is a WCAG issue.  UAAG is not one 
that should ask authors to include equivalents in more than one language, 
only that the equivalents be available to the user.

Jon

At 08:48 PM 10/29/2000 -0500, Al Gilman wrote:
>At 07:36 PM 2000-10-27 -0400, you wrote:
>[in part]
> >which means that a user agent can identify the target of
> >the link as an alternative in French (at least, can recognize
> >the author's intent, even if what the user agent retrieves
> >may not be a document in French). Does expanding the scope
> >of checkpoint 2.3 mean that the user agent must make available
> >alternatives in other languages? Or should UAAG 1.0 be
> >limited (beyond providing access to all content), to making
> >requirements related to alternatives that have an
> >impact on accessibility?
>
>Question for the working group:
>
>The above discussion makes it sound as though selecting among texts on the
>basis of natural language is not "alternatives that have an impact on
>accessibility."  Let's think about that.
>
>Let us consider the following ideas and questions:
>
>Text is regarded as presentable in sound (audio) because text-to-speech
>technology is being treated as readily available for the user.
>
>Text-to-speech technology is language-dependent.  The text-to-speech
>transformer needs to know the natural language of the text, and is capable of
>transforming selected languages.
>
>Is it true that text is only presentable comprehensibly as sound on the user's
>system if it is in a language with which the user's installed text-to-speech
>technology copes?
>
>Is it true that it is not reasonable to expect the user to have text-to-speech
>technology installed that can process all natural languages?
>
>Is it reasonable, therefore to say as a matter of fact that selecting among a
>range of texts which say substantially the same thing in different languages
>_is an accessibility requirement_, because the user is reasonably likely to
>have text-to-speech technology that will speak some languages and will not
>speak others?
>
>Al
>
> >Hello,
> >
> >Per our action item of the 26 October teleconference [1] related
> >to issue 321 [0], Eric and I would like to propose the following
> >change to checkpoint 2.3 (from the 23 October draft [2]).
> >The change uses the term "alternative" instead of "equivalent"
> >and we explain why below.
> >
> ><OLD>
> >2.3 Provide easy access to each equivalent and each equivalency target
> >through at least one of the following mechanisms: (1) allowing
> >configuration to render the equivalent instead of the equivalency
> >target; (2) allowing configuration to render the equivalent in
> >addition to the equivalency target; (3) allowing the user to select
> >the equivalency target and then inspect its equivalents; (4) providing
> >a direct link to the equivalent in content, just before or after the
> >equivalency target in document order. [Priority 1]
> >
> >Note: For example, if an image in an HTML document has text equivalents,
> >provide access to them (1) by replacing the image with the rendered
> >equivalents, (2) by rendering the equivalents near the image, (3) by
> >allowing the user to select the image and then inspect its equivalents,
> >or
> >(4) by allowing the user to follow readily available links to the
> >equivalents.
> ></OLD>
> >
> ><NEW>
> >2.3 For any element, provide easy access to each of its alternatives
> >through at least one of the following mechanisms: (1) allowing
> >configuration to render the alternative instead of the element; (2)
> >allowing configuration to render the alternative in addition to the
> >element; (3) allowing the user to select the element and then inspect
> >its alternatives; (4) providing a direct link to the alternative in
> >content, just before or after the element in document order.
> >[Priority 1]
> >Note: For example, if an image element in an HTML document has an
> >alternative in the form of a text equivalent, provide access to
> >the text equivalent through at least one of the following
> >mechanisms (1) by replacing the image with the rendered text
> >equivalent, (2) by rendering the text equivalent near the rendered
> >image,
> >(3) by allowing the user to select the image and then inspect the
> >text equivalent, or (4) by allowing the user to follow a link
> >just after the text equivalent.
> >
> >Definition of "Alternative relationship, alternative" :
> >
> >  In the context of this document, an alternative relationship between
> >two
> >  pieces of content means that one piece is intended by the author to
> >serve
> >  nessentially the same function as the other. For requirements in this
> >  document related to alternative relationships,
> >  the user agent is only responsible for those it can recognize
> >  (generally through markup). In the absence of markup that indicates
> >  otherwise, an equivalency relationship recognized by the user agent
> >  is presumed to indicate the author's intent to present alternatives
> >  (i.e., the equivalent and the equivalency target).
> >
> ></NEW>
> >
> >Note: The term "alternative" appears in our document in a few places
> >(not
> >many, in fact) and these would need review to ensure consistency. At
> >first
> >glance, they don't seem to problematic.
> >
> >======
> >Comment
> >======
> >
> >Summary: Why use "alternative" instead of "equivalent"? In our
> >document, the definition of "equivalent" has accessibility
> >implications built-in. The term "alternative" describes the author's
> >intention in creating a relationship between two pieces of content.
> >Those pieces of content may have the additional relationship
> >of "equivalency" when they satisfy the definition of "equivalency"
> >and one has the potential for providing information to a user with
> >a disability.
> >
> >The definition of equivalent begins:
> >
> >   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.
> >
> >Let's call the equivalent "A" and the equivalency target "B".  When
> >someone using this document says that "A" is equivalent to "B", they are
> >making an assertion that content "A" is capable (with the various
> >caveats and
> >assumptions stated in the definitions) of providing the same
> >functionality
> >to a person with a disability as content "B" can provide to a person
> >without a
> >disability. Please refer to the definitions of "equivalent" and "text
> >equivalent" for more detail.
> >
> >A very specific but important kind of equivalent is the text equivalent.
> >
> >It is very important to note the following:
> >
> >1. Even a valid assertion that something is an equivalent does not
> >necessarily mean that it is accessible. For example, the text may be too
> >complex (even in is simplest expression) for someone to understand.
> >Or, the person may not have a braille reader to read it.
> >Similarly, a valid assertion that something is an
> >equivalency target does not mean that the target is "inaccessible"
> >(though
> >WCAG 1.0 specifically _requires_ a text equivalent for each element
> >that is presumed to be "inaccessible" due to being a non-text element).
> >
> >2. The definition of equivalency allows authors to identify
> >equivalency relationships that are not required by specifications.
> >For example, even though no W3C specification requires an
> >English language translation of French language document, one could
> >potentially specify a text equivalence relationship between two
> >documents,
> >one of which is a language translation of the other, if the two meet the
> >definition of text equivalency. (This is related to the last sentence of
> >item 1, above).
> >
> >3. The definition of equivalency in our document does not imply or
> >require
> >that either piece of content (equivalent or equivalency target) is
> ><em>intended</em> by the author for audiences of a certain disability
> >status.
> >For example, the equivalency relationship does not denote that the
> >author <em>intended</em> the equivalent to be for a user with a
> >disability.
> >Acknowledging the risks of using terms with "loose" definitions,
> >we would say that the definition of equivalency does not assume
> >that the equivalency target is the "primary content" (i.e., for
> >general audiences (?)) or that the equivalent "alternative content"
> >(i.e., for specific disability audiences (?)).
> >
> >4. The general definition of "equivalent" does not go so far as to say
> >which
> >users with which disabilities may find the equivalent accessible.
> >However,
> >the definition of text equivalent, a specific and important kind of
> >equivalent,
> >makes that concrete. When an author provides a text equivalent for an
> >image,
> >he or she is asserting that text equivalent (content "A") is able to
> >serve
> >essentially the same function for a persons in three classes of
> >disability
> >with threespecific sets of media presentation technologies
> >(visually-displayed
> >text for individuals who are deaf, synthesized speech for people who are
> >blind,
> >and braille for individuals who are deaf-blind) -- "at least insofar as
> >is
> >feasible, given the nature of the disability and the state of
> >technology" --
> >as the image (content "B") does for a person without any  disability.
> >Quite
> >a mouthful, but that is the assertion. (See definition of "text
> >equivalent"
> >for additional assumptions.)
> >
> >5. The definition of equivalency does not assume that the equivalency
> >target
> >is more "complete" than the equivalent in conveying its message. For
> >example, a picture is not necessarily more "complete" or adequate than
> >its
> >text equivalent.
> >
> >6. This document requires that all users have access to all content.
> >This
> >document does not say that users with disabilities only need access to
> >the
> >equivalent.
> >
> >======
> >ISSUE
> >======
> >
> >Enlarging the scope of 2.3 from equivalency relationships
> >to alternatives in general may have implications on what is
> >being asked of the user agent. For example, a document in
> >French may be an alternative to an English version. In HTML,
> >one can write:
> >
> >    <a lang="fr" rel="alternate" ...>
> >
> >which means that a user agent can identify the target of
> >the link as an alternative in French (at least, can recognize
> >the author's intent, even if what the user agent retrieves
> >may not be a document in French). Does expanding the scope
> >of checkpoint 2.3 mean that the user agent must make available
> >alternatives in other languages? Or should UAAG 1.0 be
> >limited (beyond providing access to all content), to making
> >requirements related to alternatives that have an
> >impact on accessibility?
> >
> >Regards,
> >
> > - Ian
> >
> >[0]
><http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#321>http://server
>.rehab.uiuc.edu/ua-issues/issues-linear.html#321
> >[1]
> ><http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0154.html>http:
>//lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0154.html
> >[2]
><http://www.w3.org/TR/2000/WD-UAAG10-20001023/>http://www.w3.org/TR/2000/WD-
>UAAG10-20001023/
> >
> >--
> >Ian Jacobs (jacobs@w3.org)
><http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
> >Tel:                         +1 831 457-2842
> >Cell:                        +1 917 450-8783
> >

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Monday, 30 October 2000 12:39:52 UTC