Equivalency, Languages, Checkpoint 2.3

INTRODUCTION

This memo concerns comments posted by Ian on "Proposal for issue 321:
Equivalency relationships and the wording of checkpoint 2.3" [1]. This memo:

1. Examines considerations the went into that proposal.
2. Suggests possible revised wording for checkpoint 2.3.
3. Discusses the application of the concept of 'equivalency' in the context
of language translations.
4. Makes an appeal for precision in characterizing the cause of
bi-polarity/assymetry/uni-directionality in the relationship between the
equivalent and the equivalency target.

FACTORS CONSIDERED

I just wanted to give a little bit of background into some of the factors
that Ian and I tried to take into account in that proposal. If I am
incorrect in this characterization, I invite Ian to correct me.

One reason that I bring this up is that in the discussion that I have seen
on the list, I am wondering whether in proposing this revised wording we
were working from the right assumptions.

Consideration #1: Desire for bi-directional navigation. 

I think that we sensed that some members of the working group wanted to
require bi-directional navigation, i.e., both (1) from an equivalent to the
equivalency target and (2) from the equivalency target to the equivalent.

I can see how this might be helpful, especially given that there is nothing
in the definition of 'equivalency ' that denotes either the equivalent or
the equivalency target should be presented 'first' or is the 'primary' or
'default' content.  I suppose that implied in a revised checkpoint 2.3 would
be the idea that one could configure the user agent to go in either
direction.

However, I am reasonably confident that this limited objective can be
achieved with coining new "Terms of Art" (alternative relationship,
alternative, etc.). Early attempt at this are found in [2]. 

Following is a new attempt to provide bi-directional navigation. I think
that except for the introductory phrase: ("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:") it is
virtually identical to the proposal posted by Ian [1]. Note that it uses the
term 'equivalency group' and uses the term 'alternative' in a generic,
common-sense way rather than coining a new 'term of art' ('Alternative
relationship', etc.).  Thus, this approach builds on the framework of
'equivalency' rather than introducing 'Alternative' as a term of art.

<NEW>
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.

====

Comment 1:

This approach does not define how user agent developers might handle cases
in which the element of an equivalency group is in many pieces. I don't
think that we need to or can afford to go into such detail. 

Comment 2:

This checkpoint follows in line with checkpoint 2.1 that requires access to
"all content" with all the advantages and disadvantages of that requirement.

====

For comparison, here is the proposal from [2]:

<NEW>
2.3 For any element, provide easy access to each of its alternatives 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 "Alternative relationship, alternative" :

In the context of this document, an alternative relationship between two
pieces of content means that one piece is intended by the author to serve
nessentially the same function as the other. For requirements in this
document related to alternative relationships, the user agent is only
responsible for those it can recognize (generally through markup). In the
absence of markup that indicates otherwise, an equivalency relationship
recognized by the user agent is presumed to indicate the author's intent to
present alternatives (i.e., the equivalent and the equivalency target).

</NEW>

And here is the version in the 23 October (Last Call) draft:

Old (23 October 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 the user to 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

====

Consideration #2: Desire for the checkpoint to cover a broader range of
relationships other than 'equivalency relationships' (such as language
translations).

I believe that Ian and I were trying to respond to what we heard as a desire
that the checkpoint cover a broader range of relationships between content.
However, at this moment I am not sure what those relationships would be.
Since some recent discussion has focused on the issue of language
translations, I will consider that now in some detail.

The issue of language translations is an interesting one. I presume that we
are all agreed that there is not any WCAG 1.0 requirement to provide
translations in to other natural languages, though there are some
language-related checkpoints. Keeping in mind the absence of any WCAG 1.0
requirement for language translations, I have concern if language
translations are the only broadening that we can think of for checkpoint
2.3. I think that if we are making substantial changes to the wording of 2.3
and especially if we are coining new terms of art, then I think that it is
important to have a more substantial rationale.

In addition, I think that the existing (23 October 2000) concept of
'equivalency' can be more helpful regarding language translations than we
might have supposed. 

Let us consider a few cases:

==

Case 1: Two Text Elements

For example, suppose that document A is in English and document B is a
French translation of document A. Now suppose that both documents are text
elements. If this is the case, then it is perfectly legitimate, given the
current definition of equivalent, to mark document A as a text equivalent
for document B and, conversely, to mark document B as a text equivalent for
document A. Why is this permissible? Simply because they meet the definition
of text equivalent, i.e., document A when rendered as visually-displayed
text, synthesized speech, and braille to the reference disability groups
fulfills essentially the same function as does document B does for a person
without a disability. And, as noted, document B does the same for document
A. 

Case 2: Two Non-Text Elements

In Case 2, let us take the same situation, but this time, suppose that both
document A (English) and document B (French) are 'non-text elements',
perhaps because they contain a picture in addition to prose text. Remember
that both documents convey the same message but in different natural
languages. Now let us ignore for a moment the text equivalents that must be
produced for these per WCAG 1.0. I would claim that, given appropriate
markup, one could _still_ claim that document A is an 'equivalent' --
specifically, a 'non-text equivalent' -- for document B, and that,
conversely, document B is a non-text equivalent for document A. Such
non-text equivalents could still be helpful for some people with
disabilities, for example, people with physical disabilities who have
mobility difficulties but have no trouble understanding visually-displayed
text and pictures; in doing so, the pair meets the established definitions
of 'equivalency relationship' and 'non-text equivalent'.

Case 3: One Text Element and One Non-Text Element

In Case 3, for completeness, let us consider a case in which document A
(English) is a non-text element and document B (French) is a text element.
The fact that document is a text element and the other is a non-text element
suggests that perhaps the two documents may not be exact translations of
each other. However, disregarding that problem, it is possible (though due
to the inexactness mentioned earlier, not sure) that document B (a text
element) _could be_ a text equivalent of document A (a non-text element).
Conversely, it is possible (though due to the inexactness mentioned earlier,
not sure) that document A (a non-text element) could be a non-text
equivalent of document B (a text element).

==

One can see from these three cases that, with proper markup, checkpoint 2.3
in its current (23 October 2000) version can already handle some language
translation situations.

At the same time, I think that we all agree, issues of internationalization
are not our prime concern, and without greater emphasis on such issues by
other working groups (e.g., WCAG), we should not try to move into
internationalization in a major or direct way. If the concept of
'equivalency' can handle diverse language translation situations, so much
the better, but, barring strong input from others on this topic during this
last call period, this should remain a secondary consideration.

By the way, I think that it is important to note that in constructing markup
languages, it is will probably be important for author to be able to
indicate whether or not a certain instance of an equivalency relationship
was required by an accessibility specification (e.g., WCAG 1.0). And the
focus of our document should remain primarily on those that are required by
WCAG 1.0. 

Consideration #3: Desire to change to the definition of 'equivalency', etc.

Ian and I were not assigned to modify the definition of equivalent and we
did not change it, although we generated a list of clarifications that might
be a useful part of a glossary entry. However, as the reader will note, most
of those things are simply explaining what an equivalency relationship does
_not_ denote (e.g., does not denote whether the equivalency relationship is
required by specification, etc.). These things can generally inferred from
the definition of equivalent and the principle that 'The definition means
(almost) _exclusively_ what it says, and that's all'.

I think that in view of some of the comments on the list, I should reiterate
that the fundamental thing that makes the equivalency relationship bi-polar
(uni-directional, asymmetrical) is _not_ inexactness of information between
the equivalent and the equivalency target. The bi-polarity is a consequence
of having a person with a disability at one end and person without a
disability at the other end. The reason for this bi-polarity is merely to
ensure that the notion of equal access is built into the concept. The
content at one end has to fulfill essentially the same function for a person
with a disability (insofar as is possible given the state of technology and
the nature of the disability) as some other content does for a person
without any disability. To say that some content is an equivalent for other
content (the equivalency target) is to make an assertion (or claim) that
under some specific set of conditions (available hardware software, etc.),
the equivalent will fulfill the same 'feasible essential function'. Thus, in
terms of fulfilling the 'feasible essential function', an image is precisely
equal to its text equivalent. (Of course, we do not provide specific
criteria for determining what is 'feasible', but I don't think that is makes
sense to try to spell that out in great detail.)

Thus, I would hope that when people refer to some content being only
"roughly" equal (or equivalent) to some other content, they will be more
precise about what they mean. Do they mean that what one can feasibly convey
by a picture to certain audiences only roughly approximates what can be
conveyed by descriptive text to the same or different audiences? If that is
the case, please keep in mind that the existing definitions of equivalent
already take into account different delivery modes to different audiences
and they already take into account the concept of feasibility. If we want
another term that has a looser standard of similarity (e.g., 'rough
facsimile', 'rough analog', etc.), then we ought to give it a more precise
meaning. But in my opinion to say that an 'equivalent' is only approximately
or 'roughly' equivalent to its 'equivalency target' is imprecise and, in
some discussions that require precision, is simply misleading. 

====

CONCLUSION 

I hope that we consider changes to the current checkpoint 2.3 (23 October
2000), we will look carefully at what is really necessary. If the proposed
revision [1] is good then I hope that people step forward and support it. If
it has shortcomings, I hope that people will be specific about what changes
they feel are needed.

I will state my own preference to use already-defined terms when possible
rather than coining new 'terms of art'. I am at least a little bit concerned
about whether there is enough new material addressed by the concept of
'alternative relationship' that cannot already be handled reasonably well by
'equivalency relationship'. And if there is new material to be handled by
new terms (such as 'alternative relationship'), I would like to know what
that material consists of and whether it warrants Priority 1 treatment in
checkpoint 2.3. At this moment I think that:

(1) The concept of 'equivalency' in the current (23 October 2000) draft can
handle some language translation needs.
(2) Language translations are not our main concern in UAAG 1.0 and should
not, in themselves, drive major changes in the document or in checkpoint
2.3.
(3) Bi-directionality of navigation, if believed to warrant Priority 1
treatment in UAAG checkpoint 2.3, could be added without coining major new
'terms of art' ('Alternative relationship'). (See suggested new wording that
uses the term 'equivalency group'.)
(4) If working group members or others want greater breadth of coverage in
checkpoint 2.3 (e.g., beyond equivalency), then we need to identify what
that greater breadth would consist of.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0157.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000OctDec/0103.html

<END OF MEMO>

Received on Tuesday, 31 October 2000 17:23:57 UTC