Re: Proposal for issue 321: Equivalency relationships and the wording of checkpoint 2.3

Al Gilman wrote:
> 
> Question for the proposers:
> 
> Did you intend this rewording to separate the issue of "how to state
> Checkpoing
> 2.3" from the outstanding issue of "the wording of the 'equivalent (for
> content)' entry in the glossary"?
> 
> The last parenthetical aside in the NEW language for 2.3 below appears to tie
> them together, still.
> 
> How do you view this?

It was very hard to separate the issues because of the way the
word "equivalent" is already defined in the document. We could
not simply use the word "equivalent" in 2.3 and say "provide
access to each element of each set of things considered equivalent"
because "equivalent" has built-in meaning related to accessibility
in the document.

Therefore, we chose another word: "alternative". We didn't
touch the definition of equivalent.

 - Ian


> At 07:36 PM 2000-10-27 -0400, Ian Jacobs wrote:
> >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
> >

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Sunday, 29 October 2000 20:44:20 UTC