Re: Equivalency, Languages, Checkpoint 2.3

At 06:36 PM 2000-11-01 -0600, Jon Gunderson wrote:

We are going in circles.  This one may make others happier, but I distinctly
prefer the previous wording.

>How about:
>
><NEW>
>2.3 For any element with author specified equivalents, provide easy access 
>to all equivalents through one of the following mechanisms:
>(1) allowing configuration to render one the equivalents instead of the
>element;
>(2) allowing configuration to render one the equivalents in addition to the
>element;

AG:: consider options:

(1) allowing configuration to render another of the equvalents instead of the
element.
(2) allowing configuration to render another of the equivalents in addition to
the element.

or alternatively 

(1) allowing configuration to render one of the other equivalents etc. 

>(3) allowing the user to select the element and then inspect the available
>equivalents;

AG::

consider option:

(3) allowing the user to select the element and [then | while it is selected]
inspect the remaining equivalents.

Here, the square brackets and vertical bar indicate a set of alternatives from
among which the reader may select any one.  As in meta-syntax often used.

>(4) providing a direct link to the equivalents in content, just before or
>after the element in document order.

AG:: likewise...

(4) providing a direct link to the [other | remaining] equivalents in content,
etc.

Let me try to make something perfectly clear:  The generally accepted sense of
'equivalency' is that it is mutual or symmetrical.  Anyone who thinks that the
Glossary of WCAG 1.0 changes this one iota is mis-reading the WCAG and its
Glossary. 

The present glossary entry for "equivalent (for content) in the Last Call
draft
of the UAAG is an unnecessary and destructive excursion outside the bounds of
reasonable use of technical English.  It should by all means be replaced.

The sense of Checkpoint 2.3 was perfectly clear in the previous language that
Jon offered.  

The sense of the "equivalent (for content)" in the glossary is ill-conceived
and unnecessary to make any of the UAAG clear.  There are enough clear
concepts
in standard English to explain what the checkpoints actually mean in
accessible
English without introducing tortured concepts such as this one.

We should not be twisting the checkpoints out of shape to accomodate that
thoroughly twisted definition.  We should get rid of it and plainly say
what we
mean.  As Jon did, before.

Al

></NEW>
>
>Jon
>
>
>At 05:12 PM 11/1/2000 -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".
>>#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".
>>#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.
>>#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.
>>#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.
>>
>><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>
>> > >
>>
>>
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Division of Rehabilitation - Education Services
>MC-574
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: <http://www.staff.uiuc.edu/~jongund>http://www.staff.uiuc.edu/~jongund
>WWW: <http://www.w3.org/wai/ua>http://www.w3.org/wai/ua
>

Received on Wednesday, 1 November 2000 20:39:15 UTC