- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sun, 29 Oct 2000 21:24:56 -0500
- To: w3c-wai-ua@w3.org
At 08:32 PM 2000-10-27 -0400, David Poehlman wrote: >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. AG:: I want to explore this a little. On the one hand it is true that the symmetrical view, as Ian put it "looking down on the range of choices, rather than sideways from one to another" is in some ways a superior understanding of what is going on. It deals better with the fact that which one is better depends on who is the user of the moment. Which is better is not something that can be discerned from the content alone. On the other hand, historically there have been a lot of people confused by talking about 'equivalents,' here. Mostly on the basis that the tend to assume 'equivalent' should indicate a closer correspondence than what is often found in our cases. In our cases the correspondence can be pretty rough. So readers may stumble a bit if we just say 'equivalent' in the sense of "conveys some of the same information" and leave it at that. The word 'alternative' gets used in both polarized and un-polarized or symmetrical settings. We talk about giving someone an alternative when we are talking about giving them _another_ option; with implication that there is an existing or status_quo option already. But the word is also used in the 'looking down' sense as "having a range of alternatives to choose among." In this particular situation (checkpoint 2.3), it is not necessarily important to rub the reader's nose in either a looking-down or a looking-sideways perspective on the situation per se. Whether one views it as "there are multiple options available" or "there is another option available" the point is that the user needs, at their choice, to be able to gain access to any of the options. Note that the checkpoint does not require symmetrical handling of the various options, in that various forms of unequal treatment are included in the list, any one of which is credited as meeting the checkpoint. There are many situations in W3C formats where the options are treated asymmetrically in the rules of the format. The ALT attribute and OBJECT element are conspicuous examples. Then again there are other cases where what the format offers you is pretty symmetrical, such as text versions in different natural languages. So while talking about "an alternative or alternatives for something in the current view" may not be precisely the highest and best theory for the situation, it gets the user oriented adequately to understand what the checkpoint has to say. More or less. So it seems. Other thoughts? Al >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>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 > >-- >Hands-On Technolog(eye)s ><mailto:david.h.poehlman@verizon.net>mailto:david.h.poehlman@verizon.net >voice 301-949-7599 >end sig. >
Received on Sunday, 29 October 2000 20:57:24 UTC