W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

Re: Equivalency, Languages, Checkpoint 2.3

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Wed, 01 Nov 2000 18:36:44 -0600
Message-Id: <4.3.1.2.20001101183222.02914e68@staff.uiuc.edu>
To: "Hansen, Eric" <ehansen@ets.org>, "UA List (E-mail)" <w3c-wai-ua@w3.org>
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;
(3) allowing the user to select the element and then inspect the available
equivalents;
(4) providing a direct link to the equivalents in content, just before or
after the element in document order.
</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
>[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0181.html
>
>
>-----Original Message-----
>From: Jon Gunderson [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
WWW: http://www.w3.org/wai/ua
Received on Wednesday, 1 November 2000 19:36:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:22 GMT