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

I will attempt in the message below to make some clear points and have a
question or two along the way.
my insertions are marked with dp.

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).
dp if this is the case, than why not just use the relationship?  the old
checkpoint seems to me to enbody parity.
> 
> </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.
dp how so?
> 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.
dp wcag and uaag both fall short in this regard.  we talk about other
limiting factors but only actually address disabilities.  leaving the
checkpoint as is could help address the other issues in our scope
according to both introductions.
> 
> 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.
dp this should not be.
> 
> 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.
dp this says something slightly different to me.  there are several ways
to present content based on the needs or tools of the end user.  all of
them are equivalent to one degree or another given the constraints of
the target and the user.
> 
> 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.
dp that does not make for inaccessability.
> Or, the person may not have a braille reader to read it.
dp or a computer connected to the internet or whatever but we must start
somewhere.
> 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).
dp then we could limit the deffinition to text equivalants of nontext
elements.
> 
> 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 (?)).
dp that is good.
> 
> 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.
dp I would argue as above that this is not broad enough on the text
equivalant side.  
> 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?
dp I prefer that we limit the deffinition.  In order to assist
developpers, we should be as concrete in our requirements as is possible
offering requirements that are clear and that can be verifyably met.
I have never really liked the word alternative in this context but I
suppose that any symbol would end up standing for the same thing.  I do
feel that we should attempt to develop a sense of parity rather than a
relationship of either or especially due to the fact that some
disabilities and situations will require as we state in the guideline
that all the equivalancies be available at the same time.  
these are my thoughts.  Thanks for illucidating the issue.
> 
> 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

-- 
Hands-On Technolog(eye)s
mailto:david.h.poehlman@verizon.net
voice 301-949-7599
end sig.

Received on Friday, 27 October 2000 20:30:13 UTC