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

Al,
The only checkpoint related to language is that if an unsupported language 
is encountered by the user agent it should notify the user of the language 
change if configured to do so.

2.7 Allow the user to configure the user agent not to render content marked 
up in a recognized but unsupported natural
              language. Indicate to the user in context that 
author-supplied content has not been rendered. [Priority 3]

We can include an example of languages also being part of an option for 
defined equivalents.  But this requires someone to submit techniques on the 
topic.  Would you be able to submit some techniques or do you know someone 
we can ask?

I assume this is not something that can be done with the ALT attribute of 
IMG, but is possible with OBJECT and maybe SVG technologies.  ALso how does 
the LONGDESC attribute support multiple languages, other than the resource 
of the URL including multiple languages?

Jon


At 11:39 PM 10/30/2000 -0500, Al Gilman wrote:
>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
> >

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 Tuesday, 31 October 2000 14:13:05 UTC