Primary content -- OK as a "Fuzzy" Concept?

I am trying to think about what is the _least_ that we can get away with
saying about 'primary content' that will (a) have checkpoint 2.3 make sense,
(b) be compatible with the usage of the term in this and other WAI
documents, and (c) will allow the greatest possible 'wiggle room' (i.e.,
flexibility) for getting more specific later. 

UAAG (1 September 2000) reads:

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

One the face of it, this usage of the terms "primary content" and
"alternative content" seem to be generally consistent with the way that the
term 'primary content' has been used. Realizing that 'primary content' has
fuzziness to it, we have sometimes put the word "primary" in quotes.

Now we are using it directly in a UAAG checkpoint, which gives me some
unease. Maybe it is okay to do as long as we understand some of the
ambiguities. 

Following are some facets. Most of the early facets have some fuzziness and
when you put them all together you can't help but get concepts that are
fuzzy and, hence, a lot of undefined territory at the "edges."

PC = "Primary content"
AC= "Alternative content"

Facet 1: Audience
PC is almost always intended for general audiences (people without any
disability plus any people with disabilities who can make use of it) and AC
is usually for people with disabilities.

Facet 2: Equivalent versus Equivalency Target
AC often refers to "equivalents" and PC usually refers to their "equivalency
targets". Yet there are several classes of "AC" which have not as yet been
brought into an "equivalency framework"; among these are linearized versions
of tables, summaries of tables, and expansions of abbreviations and
acronyms. The stance of this checkpoint 2.3 on this point is undefined.

Facet 3: Resource Identity
PC and AC are usually produced from separate resources. However, note that a
text equivalent (presumably an AC) can come from any resource; it could even
be a mechanical transformation of the PC resource.  

Facet 4: Media Type
PC has a great mix of media types (video, audio, text), and AC tends to be
more restricted in media type (mostly 'text', plus 'auditory descriptions').

Facet 5: Optionality (per WCAG 1.0 and UAAG 1.0)
The existence of PC is not required (i.e., is optional) WCAG 1.0, but the
existence of _some_ instances of AC is required (non-optional). However, I
presume that content can be considered AC without being required by WCAG 1.0
or UAAG 1.0 specifications. (I presume that in UAAG, we only refer to AC
_accessibility_ content rather than AC _internationalization_ content,
though the requirements would likely be quite similar.)

Other Observations

1. Pre-Rendered Content vs Post-Rendering Content
Both the terms "PC" and "AC" are sometimes used to refer to pre-rendering
content and other times to post-rendering content. Both seem flexible and
therefore somewhat imprecise in this sense.

2. Scope of Accessibility Information Encompassed
Both terms seem ambiguous regarding the extent to which they encompass a
wide range of accessibility information (see Facet

My approach in trying to define the terms has been to focus on a single
facet (i.e. Facet 1): Audience. It may not be practical at his point. 

I look forward to our 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 Thursday, 21 September 2000 14:01:00 UTC