- From: Al Gilman <asgilman@iamdigex.net>
- Date: Mon, 16 Oct 2000 21:40:59 -0400
- To: Ian Jacobs <ij@w3.org>
- Cc: "UA List (E-mail)" <w3c-wai-ua@w3.org>
Just for preliminaries, let me say that I think we agree 100% on the
facts. It
is just the theories, and how theory and logic plays in the application of the
checkpoint, that we haven't quite synchronized on.
Likewise for the proposed implementation in the document, there is 98%
agreement. I have some wordsmithing to offer, but I think that may be
acceptable to you as a friendly amendment.
[In between come the screams of math teacher pain...]
At 07:55 PM 2000-10-16 -0400, Ian Jacobs wrote:
>Hello,
>
>Here's an attempt to summarize at least two issues being raised
>and my views:
>
> a) Issue 1: Can all equivalents be entirely symmetric?
>
> I believe the answer to this is no, and that means that
> the next question is moot: "Should WAI require that all
> equivalents be symmetric?"
AG::
Nobody is asking the pairs to be exactly alike. What is being asked is that
the pattern that they are checked against is symmetrical (common content in
different forms). Matching that pattern is enough to trigger the user-control
requirements of checkpoint 2.3. The rest, whether there are articulable
differences or orderings among the equivalents, does not factor in whether 2.3
applies or not. Sometimes there are and sometimes there aren't. The options
may be wildly different. But in some cases, such as subtitles which are
all in
second languages relative to the audio track, there is no intrinsic pecking
order among the choices. The purpose is to write a rule which fits the full
range of cases where we want it to apply.
The point is not that it is important to thump symmetry in the language of the
checkpoint. The point is that the condition we wish to apply is "common
[information] content in different forms." [Not _identical_ information
content in different encodings,] Because there are valid cases of this rule
where there is no proper (intrinsic to the information) ordering among the
alternatives, it is good not to thump asymmetry as though it were true in all
cases. I am just trying not to purge the rule of the appearance that it
depends on the existence of a prime/alternate polarization of the
relationship. The rule applies more generally than this common case. So we
should state the general rule.
The equivalency we are talking about is still pretty rough in many
instances.
But this is the point of the Webster quote that Eric gave us. People talk
about plane figures as equivalent when they fail to be isometric, i.e.
identical, but still have the same area, for example. The point is that
equivalent connotes a level of approximation or abstraction in the similarity
relationship, quite different from equality which would be equivalent in every
detail. The term 'equivalent,' even in its generic, symmetric sense, does not
mean 'identical.'
So when I am told, "we shouldn't treat the equivalency as symmetrical because
it is not an identity," I don't really know where to turn.
Identity guarantees equivalency, but not the reverse.
Nowhere, in arguing that the language of checkpoint 2.3 should avoid implying
asymmetry in the equivalence relationship, am I suggesting that the
language of
2.3 should imply that all equivalents are equal.
>
> [For the purposes of this email, sets of content A, B, and C
> are "symmetric equivalents" if, with the appropriate
> environment and software, they all provide exactly the
> same browsing experience to some users. I suspect that there
> will be interesting commentary on this definition...]
>
> b) Issue 2: Should we use another word than "equivalent" to
> describe relationships that may not be symmetric for the
> user?
>
> No. Refer to proposal below.
>
AG::
This is the whole point. The order relationship that matters is one that only
the user knows. That is why they have to have access to the controls. The
rule that the browser follows cannot presume to know the ordering in the
user's
assessment. So the browser threats the options as all available,
symmetrically, to the user without prejudice.
>ISSUE 1: Can all equivalents be entirely symmetric?
>
>Al writes:
> "The order [among alternatives] is often present, but it
> comes in addition to the equivalency we care about,
> not as an intrinsic part."
>
>I disagree. Listening to a symphony is not the same as reading
>a musical score of that symphony (probably for everyone, including
>gifted musicians, since there is interpretation in performance).
>I don't believe that there's a "symmetric equivalent" for a
>recorded or live symphony. Therefore, if I compose a symphony,
>any attempt to provide an equivalent will necessarily result in
>an imperfect equivalent (or alternative if you prefer to avoid
>the term equivalent here). I think there is a lot
AG::
An imperfect match or imperfect correspondence. Absolutely. But a true
fit to
the symmetric, rough-equivalence relationship, still.
By the way, expert musicians can get more out of reading a score, even in
Braille symbology, than the tonedeaf or musical illiterate gets out of hearing
a live performance by a world class symphony orchestra. The quality of the
experience is relative to both the user and the data. You can only make
statements about the data in the absence of an observer by doing numbers games
across the demographics of potential observers. It's an interesting game, but
not relevant here. All we need is a statement of the tripwire for when the
User Agent has to give the user the option as to what version they are
presented.
>of content for which the author simply cannot provide a
>browsing experience that is "exactly the same" for some
>users (including some users with disabilities). Al writes:
>
> "there is some information that is represented in each
> [alternative] that is the same in both [/all]."
> This relationship is symmetrical. This relationship is
> general. This relationship applies to an image and its alt text.
>
>Yes, there will be "some information" captured in both pieces
>of content, but not all information (due to inherent differences
>between visual data and human language). So I disagree that
>the relationship is symmetrical.
AG::
You are confusing the full particulars of a given pair with the abstract
relationship that the pair is tested against, to see whether to kick in the
2.3
consequences. But no matter; lots of others will be confused unless we
emphasize the roughness of the equivalence. [read on...]
>
>I propose that we should not attempt to apply a strict
>mathematical framework when talking about "equivalence"
>in WAI Guidelines. Or, please propose a definition
>of "symmetric" that allows one to tell mathematically
>that an image and its text equivalent are symmetric
>in meaning.
>
>ISSUE 2: Should we use another word than "equivalent" to
> describe relationships that may not be symmetric?
>
>
>2a) If we use the term "equivalent", will we confuse people?
>
> We may confuse some people, but if we explain that
> we are not using the term in its strict mathematical
> sense, I think we will be ok. As Eric has pointed out,
> the dictionary supports a non-mathematical usage.
>
>2b) Should we continue to use the word "equivalent"
> (which is already used without a requirement
> for symmetry in WCAG 1.0)?
>
> I don't have particularly strong feelings about this,
> but I think we should keep the term at least until
> we have three Recommendations that use it in the
> same way.
>
>
>PROPOSAL
>
>1) State clearly in the definition of "equivalent" that
> we don't mean mathematical equivalence. We should state that:
>
> (a) where possible, equivalents should be symmetric
> (i.e., two sets of content should provide exactly
> the same experience to some users).
>
> (b) symmetry is impossible in some cases, and ordered
> relationships will result: authors must provide
> "the closest you can get to equivalent".
>
>2) Adopt most of Eric's proposed checkpoint 2.3 [1]. I think that Eric's
> "_equivalency and similar relationships_" introduces unnecessary
> ambiguity. I think it suffices to say in the definition of
> "equivalent" that the goal should be true symmetry.
This mostly works for me. Let me offer the following wordsmithing, however.
Do talk about "the other equivalent" or "the equivalent already displayed" or
some such language, as opposed to (A,B) distinguished names for different ends
of the relationship.
In separating people from a tendency to interpret the equivalency too
strongly,
we probably shouldn't talk about what we don't mean as 'symmetry.' 'Equality'
comes closer to capturing it. For example, we could say:
"The equivalency can be pretty rough. While the goal in providing equivalents
should be comparable functionality, to count as an equivalent something simply
has to offer a feasible alternative means of getting at some of the same
information."
Something more or less like that statement will, I hope, make what we
expect in
the way of equivalency clear.
Al
>
> [1]
><http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0092.html>http:
//lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0092.html
>
>3) Delete "equivalency target" from the document (since only used
> in the glossary based on Eric's rewrite of 2.3).
>
> - Ian
>
>
>Al Gilman wrote:
>> An issue that I raised, and one you [Eric Hansen]
>> did not address, is seeking reasons
>> (either
>> way) why checkpoint 2.3 _should_ be built using a more ordinary,
symmetrical
>> model of equivalency, or the ordered relationship reflected in the language
of
>> the current draft.
>>
>> The alternative to the present language would be to take equivalency as
"there
>> is some information that is represented in each, that is the same in both
>> [/all]." This relationship is symmetrical. This relationship is general.
>> This relationship applies to an image and its alt text. It applies to the
>> different-language subtitles for the same movie. The point of building the
>> rule in this way is that it covers the widest range of cases with one
>> rule. It
>> subsumes what people with disabilities need under a more general principle
>> that
>> benefits everyone.
>>
>> We fought long and hard to get the "author proposes, user disposes"
protocol
>> established as the law of !important in CSS.
>>
>> The purpose of 2.3 is to extend the guarantee of "author proposes, but user
>> disposes" to view control concerning any feasible choices in the view
>> extraction which can yield better usability for the user and still convey
the
>> same information for the author.
>>
>> We should not be writing the checkpoint narrower than that (unless we then
>> have
>> multiple checkpoints for coverage).
>>
>> Because of the breadth of applicability, the principle is somewhat
abstracted
>> from the particulars of many of the cases. I agree it is a bit of a
>> stretch to
>> get people to think of the relationship between an image and a text phrase
as
>> one of equivalence. So the applicability is not totally obvious. But
people
>> can understand it when they think about it. Many of the interesting cases
are
>> polarized or ordered in some sense, but by using the equivalency
relationship
>> (which is not so polarized or ordered) as the basis for applying the rule,
we
>> get to all the cases that we need to cover, whether there is some
additional
>> order or precedence among the equivalents or not. The order is often
present,
>but it comes in addition to the equivalency we care about, not as an
>intrinsic
>part.
>>
>> It may be argued that this is an internal matter to be settled whithin the
>> UAAG. On the other hand, PF has a dependency on this point. In dealing
with
>> people defining new formats, it really helps PF to have the simple, broad
>> versions of the rule be what shows through clearly and consistently as the
WAI
>> message from all corners. That is why I have objected to the way that 2.3
is
>> presently stated.
>>
>> Whenever the abstract, un-polarized relationship is true, the user
should be
>> able to exercise control over which of the choices is exposed in the actual
>> view of the content. If we put a more narrow test in the applicability
>> section of the rule, we run the risk that the rule as defined will not
>> apply to
>> all cases where it is needed.
>>
>> Sorry not to give you a point by point reply, but I don't find your points
>> reflect what I was getting at very well. So I have tried to assert afresh
>> what
>> I do see as the issue,
>>
>> Al
>>
>> >
>> >====
>> >
>> >Question 1. Is the term "equivalent" the best term for expressing a
>> >uni-directional relationship between pieces of content?
>> >
>> >Response:
>> >
>> >You have, in effect, posed the question as to whether the term
"equivalent"
>> >is the best way to express such a uni-directional relationship.
>> >
>> >In order to address this question, I want to start where I think (and
hope)
>> >that we can all agree. Specifically, I don't think I hear any disagreement
>> >about whether the UAAG (29 September 2000) conception of equivalency is
>> >uni-directional (asymmetrical). The concept of equivalent is summarized in
>> >the following sentence from the definition of "Equivalent" in the
glossary.
>> >
>> >"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." (UAAG, 29 September 2000, definition of
>> >'Equivalents (for content)')
>> >
>> >Note that under this definition, just because content A is an equivalent
for
>> >content B does _not_ necessarily mean than content B is an equivalent for
>> >content A. Thus, the relationship is uni-directional (asymmetrical) as
>> >opposed to bi-directional (symmetrical).
>> >
>> >Now let us get back to the question of whether the terms "equivalent",
>> >"equivalency target", and "equivalency relationship" can make sense for
such
>> >a uni-directional relationship.
>> >
>> >Let us consider the following excerpts the range of meanings found in the
>> >entry for "equivalent" in the on-line Merriam-Webster Dictionary [5]:
>> >
>> >"1 : equal in force, amount, or value; also : equal in area or volume but
>> >not admitting of superposition <a square equivalent to a triangle>"
>> >"2 a : like in signification or import b : having logical equivalence
>> ><equivalent statements>"
>> >"3 : corresponding or virtually identical especially in effect or
function"
>> >"4 obsolete : equal in might or authority"
>> >"5 : having the same chemical combining capacity <equivalent quantities of
>> >two elements>"
>> >"6 a : having the same solution set <equivalent equations> b : capable of
>> >being placed in one-to-one correspondence <equivalent sets> c : related by
>> >an equivalence relation"
>> >
>> >Some have expressed concerns that the UAAG concept of equivalent does not
>> >match meaning #1 ("equal in force, amount, or value"). Yet consider the
>> >other meanings. For example, meaning #6b ("capable of being placed in
>> >one-to-one correspondence") seems very compatible with our usage of the
term
>> >as does meaning #2b ("having logical equivalence <equivalent
statements>").
>> >Meaning #2a ("like in signification or import") and meaning #6c ("related
by
>> >an equivalence relation") appear related, but not as directly.
>> >
>> >My conclusion from this review is that our usage of the term is well
within
>> >the acceptable range of meanings for the term "equivalent".
>> >
>> >It might be possible (or might have been possible) to find a different
word,
>> >other than "equivalent" that would convey the uni-directional nature of
>> >"equivalent" and thereby avoid the sense of concern that we feel about the
>> >fact that our usage of equivalent does not match perfectly meaning #1 of
>> >equivalent ("equal in force, amount, or value").
>> >
>> >In conclusion, I have no problem with trying to find words that better
>> >express the uni-directionality of the relationship between an equivalency
>> >target and its equivalent. But at the same time, I am not persuaded that
our
>> >current usage is seriously flawed.
>> >
>> >====
>> >
>> >Question 2. Is the UAAG conception of equivalency fundamentally different
>> >from that expressed in WCAG?
>> >
>> >Response:
>> >
>> >You have indicated that the UAAG concept of equivalency is contrary to
that
>> >expressed in WCAG (1.0). You stated:
>> >
>> >"The "equivalent vs. equivalency target" definitions in this volume are
not
>> >the same definition of "equivalent" as in math, English or the _WCAG_ and
>> >the math, English and _WCAG_ sense is appropriate in this context, and the
>> >usage currently in the draft is not." ([1], emphasis added)
>> >
>> >Although you did not seem to elaborate on this particular issue,
insofar as
>> >I understand your concern, I disagree.
>> >
>> >Ian is correct in his suggestion that in crafting language for the UAAG
>> >definition of equivalent, I was trying to remain consistent with what is
>> >found in WCAG 1.0 [2].
>> >
>> >The WCAG 1.0 definition 'Equivalent' states:
>> >
>> >"In the context of this document, the equivalent must fulfill essentially
>> >the same function for the person with a disability (at least insofar as is
>> >feasible, given the nature of the disability and the state of technology),
>> >as the primary content does for the person without any disability." (WCAG
>> >1.0, definition of 'Equivalent')
>> >
>> >Please note that this definition, like that of the UAAG definition of
>> >equivalent, is uni-directional. The basic changes that we have in UAAG is
>> >that we give the relationship a name ("equivalency relationship") and that
>> >instead of using the term 'primary content' we use the term 'equivalency
>> >target'. I think that Ian would agree that the term 'primary content' has
>> >long been a 'fuzzy' (ambiguous) term that we haven't felt entirely
>> >comfortable with. I think that the working group is acquainted with my
>> >efforts to find a good definition for the term 'primary content'. And when
I
>> >proposed the term 'equivalency target' [3], the working group accepted it
>> >[4]. As noted in the minutes [4], working group members seemed to
appreciate
>> >its simplicity and that it neutralizes or eliminates some of the negative
>> >connotations that seemed associated with some definitions of 'primary
>> >content'.
>> >
>> >In conclusion, I find the UAAG concept and definition of equivalency
>> >fundamentally in line with what is expressed in WCAG. Most to the point,
>> >both the UAAG and WCAG conceptions of equivalent are uni-directional
>> >(asymmetric) in their equivalency relationship.
>> >
>> >====
>> >
>> >3. Is the current UAAG conception of equivalency simply the
>> >"primary/alternative" distinction but in different words?
>> >
>> >Response:
>> >
>> >You indicated that "The current language (in the 29 Sept. Draft) is just
>> >primary/alternate content under new labels." I am reasonably certain
that I
>> >disagree. I would be more certain if I knew that we were agreed about the
>> >meaning of the "primary/alternate" distinction. As I mentioned earlier in
>> >this memo, the term "primary" has long been known to have some
ambiguity in
>> >it. And as you know, I struggled for quite a while trying to bring about
>> >some consensus regarding the meaning of "primary content" ([6], [7], [8],
>> >[9]) but ultimately failed [3].
>> >
>> >Notwithstanding some uncertainty about what is or should be meant by the
>> >term "primary content", I think I understand what you are referring to and
>> >will try to respond on that basis.
>> >
>> >I surmise that you think that the UAAG distinction "equivalency target
>> >versus equivalent" is another name for the distinction "content intended
for
>> >people _without_ disabilities versus content intended for people _with_
any
>> >disabilities". A number of people found the latter distinction
troubling in
>> >my discussion of "primary content"; in that context the distinction went
>> >under different names, sometimes "primary content/secondary content" and
>> >other times "primary content/alternative content".
>> >
>> >As I indicated in a recent telecon, I have revised some of my thinking
about
>> >the relevance and value of this distinction ([3], [4]). For the record, I
>> >will say that I think a better name for the distinction might be "core
>> >content" (intended for audience without any disabilities, plus any people
>> >with disabilities who can benefit from it) and supplementary content
>> >(intended for audience with disabilities who find the core content
>> >inaccessible).
>> >
>> >If this is what you meant when you indicated that "The current language
(in
>> >the 29 Sept. Draft) is just primary/alternate content under new labels"
then
>> >I disagree and will attempt to show how these distinctions are
different. I
>> >will say that I expected this concern would arise and have been looking
>> >forward to the opportunity to clarify this point.
>> >
>> >The idea I would like to get across this: The concept of equivalency as I
>> >have been trying to articulate it is neutral_ as to whether any or both of
>> >the two pieces of content -- equivalent or equivalency target -- are
>> >intended for people with a certain disability status (e.g., with
>> >disabilities versus without disabilities). This means, for example, that
>> >there is nothing in the basic meaning of equivalent or equivalency target
>> >that denotes that one is intended for people with disabilities and one is
>> >for people without disabilities.
>> >
>> >This may seem surprising since the UAAG definition of equivalent, which
>> >says:
>> >
>> >"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." (UAAG, 29 September 2000, definition of
>> >'Equivalents (for content)')
>> >
>> >This definition makes clear reference to a person _with_ a disability at
the
>> >'equivalent' end of the relationship and a person _without_ a
disability at
>> >the 'equivalency target'. If so, then how can one then likewise affirm, as
I
>> >do, that my concept of equivalency "is _neutral_ as to whether any or both
>> >of the two pieces of content -- equivalent or equivalency target -- are
>> >intended for people with a certain disability status (e.g., with
>> >disabilities versus without disabilities)"?
>> >
>> >The answer is essentially this: Just because content X serves essentially
>> >the same function for a person _with_ a disability and as content Y does
for
>> >a person _without_ a disability DOES NOT MEAN that the author intends
>> >content X for persons _with_ disabilities and content Y for people
_without_
>> >disabilities. The author's intended audience for a piece of content is
_not_
>> >denoted by its status as an equivalent or as an equivalency target. That
>> >intention, insofar as it is important, must be designated by another means
>> >or, if necessary, guessed at. Let us consider an example of a Web-based
>> >instructional module that is teaching about _captions_ for multimedia
>> >presentations (movies, etc.) and that this instructional module is
designed
>> >for all audiences. The captions are a kind of equivalent, specifically a
>> >text equivalent of the auditory track of the movie that is synchronized
with
>> >the visual and auditory tracks. My assertion is that even though the
caption
>> >text is a text equivalent for the auditory track of the movie, this does
not
>> >mean that the author intends those captions, in the context of that
>> >instruction, specifically for people _with_ disabilities. Indeed, as we
have
>> >said, in this case the author intends the caption text for people
_without_
>> >disabilities (as well as people with disabilities who can benefit from
>> >them).
>> >
>> >Thus, I disagree that "The current language (in the 29 Sept. Draft) is
just
>> >primary/alternate content under new labels." Personally I believe that the
>> >ability for an author to indicate that he or she intends some piece of
>> >content for persons with certain classes of disability. (I am confident
that
>> >in some applications, this capability will prove essential.) The
importance
>> >of this ability is increased by the fact that the distinction is between
>> >equivalent and equivalency target is _not_ a vehicle for conveying such
>> >information; in any given instance, one, or both, or none of the
equivalent
>> >and the equivalency target might be intended for people with disabilities.
>> >On the other hand, the disability status of the intended audience was the
>> >_defining_ characteristic of the primary/alternative (or
primary/secondary)
>> >distinction.
>> >
>> >I will reexamine the language of the UAAG document and see if there is a
way
>> >that I can clarify this issue in the document.
>> >
>> >Thanks for giving me the opportunity to discuss this point.
>> >
>> >====
>> >
>> >Question 4. Should checkpoint 2.3 be altered to take in a greater variety
of
>> >relationships?
>> >
>> >Response:
>> >
>> >Judging from comments on the list, there seems to be quite a bit of
interest
>> >in expanding the scope of checkpoint 2.3.
>> >
>> >I think that this is a very good point to bring up. Your suggestions have
>> >helped me think through my concerns about things that don't fit into the
>> >regular mold of equivalency relationships.
>> >
>> >Here is my suggestion for checkpoint 2.3:
>> >
>> >"2.3 Where multiple elements of content within a document are related by
>> >_equivalency and similar relationships_, provide easy access to each
element
>> >among the related elements. This shall be done through at least one of the
>> >following mechanisms: (1) allowing configuration to render one element
>> >instead of other related elements; (2) allowing configuration to render
more
>> >than one of the related elements; (3) allowing the user to select a
>> >displayed element and then inspect any of the other elements; (4)
providing
>> >a direct link to other related elements, just before or after a displayed
>> >element in document order.
>> >[Priority 1]"
>> >"Note: For example, if an image in an HTML document has text equivalents,
>> >provide access to them by (1) allowing configuration to replace one
element
>> >from among the image and its rendered equivalents; (2) allowing
>> >configuration to render an image plus one or more of its rendered
>> >equivalents; (3) allowing the user to select a displayed image or
equivalent
>> >and then inspect any of the other elements; (4) providing a direct link to
>> >other related elements (image or equivalent), just before or after a
>> >displayed element in document order."
>> >"Techniques for checkpoint 2.3"
>> >
>> >Also, add the following to the definition of Equivalent or in a Note:
>> >
>> >"_Equivalency and similar relationships_ include at least the following:
>> >equivalency relationships; linearizations and summaries of tables;
>> >expansions (of acronyms); abbreviations (of phrases); language
translations;
>> >titles, etc."
>> >
>> >Comment 1:
>> >
>> >I used a "defined" term "element" rather than an undefined term
"fragment";
>> >provide the example; defined the "equivalency and similar relationships".
>> >
>> >Comment 2:
>> >
>> >I presume that we don't need to mention that they only need to work with
>> >what they can recognize.
>> >
>> >Comment 3:
>> >
>> >I suspect the definition of "Equivalency and similar relationships" needs
>> >further work.
>> >
>> >
>> >Below for comparison are (1) the old (29 September 2000) version of
>> >checkpoint 2.3 and (2) Al Gilman's suggestion.
>> >
>> >Old (29 September 2000):
>> >
>> >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 select the image and then inspect its equivalents, or (4) by
>> >allowing the user to follow readily available links to the equivalents.
>> >Techniques for checkpoint 2.3
>> >
>> >Al's suggestion:
>> >
>> >2.3 Where there are multiple fragments of content within a document which
>> >are equivalent in the senses that they convey the same information,
closely
>> >or roughly; provide easy access to any equivalent among the range of
>> >equivalents.
>> >This shall be done through at least one of the following mechanisms: (1)
>> >allowing configuration to render one equivalent instead of another; (2)
>> >allowing configuration to render more than one equivalent; (3) allowing
the
>> >user to a displayed equivalent and then inspect any equivalents of the
>> >selected item; (4) providing a direct link to another (each other)
>> >equivalent in content, just before or after a displayed equivalent in
>> >document order.
>> >[Priority 1]
>> >
>> >REFERENCES:
>> >
>> >[0]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0085.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0085.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0085.html
>> >[1]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0086.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0086.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0086.html
>> >[2]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0087.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0087.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0087.html
>> >[3]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0429.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0429.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0429.html
>> >[4]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0493.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0493.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0493.html
>> >[5]
>>
<<http://www.m-w.com/cgi-bin/dictionary>http://www.m-w.com/cgi-bin/dictiona
ry><http://www.m-w.com/cgi-bin/dictionary>http://www.m-w.com/cgi-bin/diction
ary
>> >[6]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0414.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0414.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0414.html
>> >("Primary content -- OK as a "Fuzzy" Concept?")
>> >[7]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0207.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0207.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0207.html
>> >("Primary Content", etc. - Response to Ian Jacobs)
>> >[8]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html
>> >("Primary Content", etc. - Corrected!)
>> >[9]
>>
<<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html>http:/
/lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html>http://
>> lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html
>> >(""Primary Content", etc.")
>> >
>> ><END OF MEMO>
>> >
>> >===========================
>> >Eric G. Hansen, Ph.D.
>> >Development Scientist
>> >Educational Testing Service
>> >ETS 12-R
>> >Princeton, NJ 08541
>> >609-734-5615 (Voice)
>> >E-mail: ehansen@ets.org
>> >(W) 609-734-5615 (Voice)
>> >FAX 609-734-1090
>> >
>
>--
>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
>
Received on Monday, 16 October 2000 21:16:45 UTC