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

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

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 30 Oct 2000 23:39:58 -0500
Message-Id: <200010310412.XAA59394@smtp2.mail.iamworld.net>
To: w3c-wai-ua@w3.org
At 11:40 AM 2000-10-30 -0600, Jon Gunderson wrote:
>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
>

OK, I withdraw the question.

There is a potential UAAG question along the lines of "If there are
equivalents
with markup to indicate they are in different languages, is the User Agent
supposed to inform the user of the languages as shown in the markup?"  But I
see you haven't dealt with that in the checkpoints.

I was just trying to get clear that the range of options (alternatives,
equivalents, whatever we call them) that do appear in the documents are
sometimes things that would strike the casual observer as quite dissimilar
(like images and ALT strings) and sometimes things that would strike the
casual
observer as pretty much on a par (like a UN document with your choice of text
in any one of six languages).

This is not necessary for the definitive meaning of the checkpoint, as you
have
pointed out.  It could perhaps help us in understanding document usabilitity
issues -- what readers will understand easily and not so easily.

Al

>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://se
rver.rehab.uiuc.edu/ua-issues/issues-linear.html#321><http://server/>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>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/><http://www.w3.org/TR/2000/WD->http://www.w3.org/TR/20
00/WD-
>>UAAG10-20001023/
>> >
>> >--
>> >Ian Jacobs (jacobs@w3.org)
>><<http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs><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>http://www.staff.uiuc.edu/~jongund
>WWW: <http://www.w3.org/wai/ua>http://www.w3.org/wai/ua
>  
Received on Monday, 30 October 2000 23:12:13 GMT

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