Re: Equivalency, Languages, Checkpoint 2.3

At 05:12 PM 2000-11-01 -0500, Hansen, Eric wrote:
>Jon,
>
>I have a few observations about your proposal [1].
>
>#1. The meaning of the term "alternative" in this context is not clear.
>Specifically, it is not clear whether the "element" is to be considered an
>"alternative".

AG::

In standard English, anything _is_ an equivalent of itself, and is_not an
alternative for itself.  So in this situation, it is clear by standard English
logic that "an alternative" cannot refer to the same equivalent as does "the
element."  Further, "its alternatives" is guaranteed not to refer back to the
equivalent that happended to be started with as "the element."  There is
miniscule chance that someone could get confused in (4) where it says "the
alternatives" instead of "its alternatives." This small chance could be
removed
by saying "its alternatives" as in (3).

>#2. Because of issue #1, the proposal does not capture the bi-directional
>navigation that I thought was desired. My suggestion that made use of the
>term "equivalency group" tried to solve this problem by clarifying the
>meanings of "alternative" and "element". For example, the term "element" was
>used as a "role" [2] that distinguished it from the other role of
>"alternative".

AG::

I am sorry there was this confusion.  At least I, for one, was not attempting
to change what I felt to be the substance of the checkpoint, only to make sure
that the checkpoint was clearly stated.  To this end, it is helpful that this
language is clear without the need for any neologisms.

I certainly hope that it is safe to say that the user can inspect the
alternatives, and that they then can get back about their business without our
having to say that, too.  If the user agent implements this so that inspecting
the alternatives leaves the user with no return path; that user agent will, in
the market, get what they deserve.  

As I said a while ago, I read techniques (3) and (4), if either were
implemented alone in the absense of technique (1), to mean that the full
set of
equivalents, including the one mentioned as "the element" to start or
displayed
by author default to start, are not treated entirely interchangeably.  This is
not something I was trying to get changed.

Since, as the latest suggestion has demonstrated, it is possible to make the
checkpoint quite clear in plain, natural English, that is what we should do.

>#3. The term "element" is really not necessary here, since a more exact term
>-- "equivalency target" -- is already available. To use the term "element"
>here begs the question regarding which meaning of element is being referred
>to. By the using the word, "equivalency target", that ambiguity disappears.
>I suggest sticking with better-defined terms when they will do the job.

The term "equivalency target" is a good example of bad language.  It is an
oxymoron that the world, and particularly the UAAG, will do much better
without.  There is no convincing need to clarify the language that was
suggested, as it is clear and any literate reading would get the intended
meaning out of it.

Consider the quote:

2.3 For elements with author specified equivalents, provide easy access to 
all equivalents through one of the following mechanisms:
(1) allowing configuration to render one the alternatives instead of the 
element;

Here it is crystal clear from standard English that "the element" refers to
any
element satifying the prefatory restrictive prepositional phrase "For elements
with..."

Interpretation of "the alternatives" as "the other equivalents" is not
guaranteed by their dictionary meaning alone.  However, in the context of this
sentence there is no other reasonable interpretation; so the meaning is safe.

What meaning would you think that people would read into _the checkpoint_ that
is not proper?

>#4. I would recommend using singular terms where possible. For example,
>instead of "For elements with author specified equivalents, ...", say "For
>any element with author-specified equivalents, ...". This would, I think,
>clarify the intent. 

AG::

This is unnecessary, but it does also say the right thing.  The use of "the
element" in the four method descriptions makes it certain that we are dealing
with the elements selected by the 'for' phrase one at a time.

>#5. Related to issue #4 is the issue of why we exclude system-generated
>equivalency relationships from the checkpoint. The original wording (23
>October 2000 draft) does not exclude system-generated equivalency
>relationships. I have some preference for including all equivalency
>relationships, not just author-specified ones, though I think that handling
>just the author-specified ones might be okay, if there is some good reason
>to exclude them.

AG::

I would agree that 2.3 should probably apply to "user agent recognized"
equivalents, not just "author specified" equivalents, if there is any
difference.

Can anyone think of an example?  What was meant by a system-generated
equivalency?  What part of the system is generating this relationship or
content?  Is this captured in an issue that ever crossed through the issues
list?



Al
>
><JON'S VERSION>
>2.3 For elements with author specified equivalents, provide easy access to
>all equivalents through one of the following mechanisms:
>(1) allowing configuration to render one the alternatives instead of the
>element;
>(2) allowing configuration to render one the alternatives 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 alternatives 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.
></JON'S VERSION>
>
>My earlier suggestion [2] is below for comparison.
>
><ERIC'S>
>2.3 For any element intended for presentation to the user, provide easy
>access to all other elements in its _equivalency group_ 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 "Equivalency group"
>
>In the context of this document, an equivalency group is an equivalency
>target and all its equivalents. The term may also be modified to refer to a
>subset of that group, i.e., including only those equivalents that meet thus
>and such criteria.
></ERIC'S>
>
>In thinking about what revised wording might satisfy everyone, it would be
>helpful to know what objectives people have for the changes.
>
>I feel a little bit like we are just guessing at what is intended to be
>accomplished by revisions to checkpoint 2.3.
>
>Thanks!
>
>- Eric
>
>[1]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0193.html>http://
lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0193.html
>[2]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0181.html>http://
lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0181.html
>
>
>-----Original Message-----
>From: Jon Gunderson
[<mailto:jongund@ux1.cso.uiuc.edu%5D>mailto:jongund@ux1.cso.uiuc.edu]
>Sent: Wednesday, November 01, 2000 2:33 PM
>To: Al Gilman; w3c-wai-ua@w3.org
>Subject: Re: Equivalency, Languages, Checkpoint 2.3
>
>
>Al,
>How about this:
><NEW>
>2.3 For elements with author specified equivalents, provide easy access to 
>all equivalents through one of the following mechanisms:
>(1) allowing configuration to render one the alternatives instead of the 
>element;
>(2) allowing configuration to render one the alternatives 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 alternatives 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.
></NEW>
>
>Response JRG:
>At 11:41 AM 11/1/2000 -0500, Al Gilman wrote:
>>At 09:33 AM 2000-11-01 -0600, Jon Gunderson wrote:
>> >I offer the following proposal based on EH [1] proposal:
>> >
>>
>>AG:: This looks good.  I have some comments and questions, but this wording
>is
>>generally something I could go out and defend to heathens.
>>
>>-- partial quotes and comments
>>
>> >2.3 For elements with an author specified equivalents, provide easy
>access
>>
>>
>>AG:: drop the 'an,' it conflicts in number with 'equivalents.' [just
>grammar]
>
>JRG: Agreed
>
>> >to the equivalents through one of the following mechanisms:
>>
>>AG:: possible edit:
>>
>>to all equivalents through one or more of the following mechanisms:
>>
>>[rationale point 1: If 'all' vs. 'the' equivalents sends us off into
>another
>>rathole on symmetry, I can live with 'the.'  But 'all' is modestly better
>in
>>getting the message across.]
>>
>>[rationale point 2: It would probably be best to say "at least one" of the
>>following mechanisms, or "one or more" of the following mechanisms, just so
>>nobody reads this as "one and only one."  This is a little more wordy and
>>pedantic, but it is more precise and reader-proof.]
>
>JRG: Ian and Eric can help here with the final language
>
>> >(1) allowing configuration to render one or more of the alternatives
>> >instead of the element;
>> >(2) allowing configuration to render one or more of the alternatives in
>> >addition to the element;
>>
>>AG:: In options 1 & 2 I regard the addition of "or more" as better for the
>>user.  On the other hand, while small, I would tend to view this as a
>>substantive change.  Was the question of 'one' vs. "one or more" discussed
>in
>>any depth in the development of the checkpoint, or is this small difference
>>"all the same thing" at the (rough) level of precision of the existing
>rough
>>consensus?
>
>JRG: We could leave it at one, but the other options 3 and 4 already talk 
>about access ti more than one.  An option could be to say "one of the 
>alternatives " or something like that.
>
>
>
>> ><NEW>
>> >2.3 For elements with an author specified equivalents, provide easy
>access
>> >to the equivalents through one of the following mechanisms:
>> >(1) allowing configuration to render one or more of the alternatives
>> >instead of the element;
>> >(2) allowing configuration to render one or more of the alternatives 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 alternatives 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.
>> ><NEW>
>> >
>

Received on Wednesday, 1 November 2000 20:12:16 UTC