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

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
[1]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0154.html
[2] http://www.w3.org/TR/2000/WD-UAAG10-20001023/

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

Received on Friday, 27 October 2000 19:36:20 UTC