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

Re: Equivalency, Languages, Checkpoint 2.3

From: Hansen, Eric <ehansen@ets.org>
Date: Wed, 01 Nov 2000 17:12:31 -0500
To: "UA List (E-mail)" <w3c-wai-ua@w3.org>
Message-id: <B49B36B1086DD41187DC000077893CFB8B44E2@rosnt46.ets.org>
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>
> >
Received on Wednesday, 1 November 2000 17:14:17 GMT

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