"Primary Content" and "Equivalent Alternative"

From: Eric Hansen
To: UA List
Re: "Primary Content" and "Equivalent Alternative"

This memo proposes eliminating the terms the "primary content" and
"equivalent alternative" from the document and modifying checkpoints 2.1 and
2.3 and some definitions. Other changes (i.e., outside the checkpoints and
the definitions) should be able to be revised editorially.

I appreciate the comment of Gregory, Kynn, Harvey, Al, Jon, Charles, Ian,
and others to commented on the issues covered herein.

====

Suggestion 1: In the definition of "equivalent", replace the term "primary
content" with "equivalency target". 

I think that it is necessary to replace the term "primary content" in the
definition of "equivalent" (which derives from WCAG 1.0 [1]). The main
problem is the "fuzziness" (ambiguity) in the definition of the term
"primary content" as documented in my earlier memo [2]. 

At one point, I tried to reserve a special meaning for the term "primary
content" ([3], [4]) so that it focused on the distinction between content
for people with disabilities and content for people without disabilities.
However, that special meaning has not gained support as a sole meaning for
"primary content" ([5], [6]). The concept also been further been questioned
as even a "facet" of the meaning of the term "primary content" [8].
Regardless of whether the distinction is important to the definition of
"primary content", I still think that the concept has some value but I admit
that since making the proposal, several technical and non-technical issues
have led me to considerably scale back my expectation of the value of the
concept. I also have developed other language that I think better explains
the purpose of the distinction and may help deal with the perception that it
may encourage discriminatory thinking. 

Yet I submit that even if one eliminates consideration of Facet 1 (related
to that distinction between content for people with disabilities and content
for people without any disability), much fuzziness would still remain in the
definition of "primary content". For example, I submit that the concept of
'primary content' may, in the minds of some (and perhaps not just me!),
involve at least Facets 2 through 5 as well as other ideas. Al Gilman's
response ("No") to the question "Is it OK for 'primary content' to be a
fuzzy concept?" suggests that he may view the concept of "primary content"
as too fuzzy [8]. (I assume that his response was not based purely on a
reaction to Facet 1.) If one can provide a cleaner and better definition of
"primary content", one can try, but I would prefer not to invest any more in
the attempt.

I propose, instead, that we eliminate the use of the term "primary content"
in the UAAG document and instead choose different term. Specifically, I
suggest the "equivalency target". This term was suggested in about 3 August
2000 [9] if not earlier and is also mentioned in Facet 2 my analysis [2].
The key idea is that an equivalency relationship, as defined in the WAI
documents, joins two pieces of content -- one being the "equivalent" and one
being what I would call the "equivalency target". Advantages of this
terminology include the following.

1. The terms address on a single, easy to understand, concept.
2. The terms "equivalent" and "equivalency target" seem to go well together
(as well as with the term "equivalency relationship").
3. The terms emphasize the uni-directionality of the equivalency
relationship. Just because content A can serve as an equivalent for content
B does not mean that content B can necessarily serve as an equivalent for
content A.
4. The terms are completely neutral on other issues such as mechanisms for
generating or storing either piece of content and whether the equivalent is
required by specification (e.g., WCAG 1.0) or not.
5. The terms are neutral as to whether either the equivalent or the
equivalency target is intended for people with disabilities. 

====

Suggestion 2: In the glossary, define the term "equivalent" rather than
"equivalent alternatives".

The term "equivalent alternatives", to my mind, is a term that has all the
problems of the term "primary content" plus more. The phrase takes two terms
and are loaded with meaning but the meaning of the result is undefined. I
will not go into detail on this since I have already done so in great detail
elsewhere. References [10] and [11] are just one tip of the iceberg. 

Old (1 September 2000):

"Equivalent alternatives for content" [initial section]
"Since content in some forms is not always accessible to users with
disabilities, authors must provide equivalent alternatives for inaccessible
content. In the context of this document, the equivalent must fulfill
essentially the same function for the person with a disability (at least
insofar as is feasible, given the nature of the disability and the state of
technology), as the "primary" content does for the person without any
disability. 

New:

"Equivalent, Equivalency Target, Equivalency Relationship"

"In the context of this document, an 'equivalency relationship' between two
pieces of content means that one piece -- the 'equivalent' --- is able to
serve essentially the same function for a person with a disability (at least
insofar as is feasible, given the nature of the disability and the state of
technology) as the other content -- the "equivalency target" -- does for a
person without any disability. [etc.]

====

Suggestion 3: Fix checkpoint 2.3.

The following fix to checkpoint 2.3 uses the new definitions.

Old (1 September 2000):

"2.3 If content available in a viewport has equivalent alternatives, provide
easy access to the alternative equivalents through at least one of the
following mechanisms: (1) allowing configuration to render alternative
instead of primary content; (2) allowing configuration to render alternative
in addition to primary content; (3) allowing the user to select the primary
content and then inspect its alternatives; (4) providing a direct link to
the alternative in content, just before or after the primary content in
document order. [Priority 1]"
"Note: For example, if an image in an HTML document has text equivalents,
provide access to them by rendering them nearby, allowing the user to
configure the user agent to render them in place of the image, or allowing
the user to follow a readily available link to them."

New:

"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 select the image and then inspect its equivalents, or (4) by
allowing the user to follow readily available links to the equivalents."

Comment 1:

Note that the wording changes result in a much tighter fit. There is no
reason to use a less-well-defined term "alternative equivalents" when a
much-better-defined term ("equivalent") will do.

====

Suggestion 4: Fix checkpoint 2.1.

This revised checkpoint uses the more precise term "equivalent" as opposed
to the less well-defined term "equivalent alternative".

Old (1 September 2000):

2.1 Make all content available through the user interface. [Priority 1] 
Note: Users must have access to the entire document object through the user
interface, including equivalent alternatives for content, attributes, style
sheets, etc. This checkpoint does not require that all content be available
in every viewport. A document source view is part of a solution for
providing access to content, but is not a sufficient solution on its own for
all content. Refer to guideline 5 for more information about programmatic
access to content.

New:

2.1 Make all content available through the user interface. [Priority 1] 
Note: Users must have access to the entire document object through the user
interface, including recognized equivalents, attributes, style sheets, etc.
This checkpoint does not require that all content be available in every
viewport. A document source view is an essential part of a solution for
providing access to content, but is not sufficient for all content. Refer to
guideline 5 for more information about programmatic access to content.

Comment 1:

The revision also makes a few other changes. For example, it makes clearer
that document view is not optional. 

Comment 2:

The revision alludes to the idea that some things equivalents may not be
recognized. This change is probably not extremely high in importance. 

[1] http://www.w3.org/TR/WAI-WEBCONTENT/
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0414.html
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html
("Primary Content", etc.")
[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html
("Primary Content", etc. - Corrected!")
[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0409.html
(Gregory J. Rosmaita on "author-defined content vs. 'primary' content")
[6] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0410.html
(Kynn Bartlett on "author-defined content vs. 'primary' content")
[7] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0412.html (Al
Gilman on "author-defined content vs. 'primary' content")
[8] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0416.html (Al
Gilman on "Fuzzy Concept")
[9] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0207.html
[10] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999OctDec/0226.html
(Which of two suboptimal terms to use) (16 December 1999)
[11] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999OctDec/0227.html
(Ian's recollection of our WCAG discussion)
===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090

Received on Monday, 25 September 2000 18:47:17 UTC