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

"Primary Content", etc. - Response to Ian Jacobs

From: Hansen, Eric <ehansen@ets.org>
Date: Thu, 03 Aug 2000 23:30:08 -0400
To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
Cc: "Hansen, Eric" <ehansen@ets.org>
Message-id: <A12997152E36D31187A4000077893CFB036FC478@rosnt46.ets.org>
Date: 3 August 2000
To: UA List
From: Eric Hansen
Re: "Primary Content", etc. - Response to Ian Jacobs

Following shows my responses to Ian Jacob's 28 July response [2] to my 27
July memo entitled "'Primary Content', etc." [1]. Please note that Ian had
not yet seen my 28 July memo ("Primary Content", etc. - Corrected!) [3]. 

IJ = Ian Jacobs
EH = Eric Hansen




Thank you for taking the time to construct this compelling missive!
I wouldn't have expected any "less" from you. <wink>. I've
included the email in its entirety after my signature.

I have some comments and questions about some of your
more salient points:

1) Primary content is "content (meaning #1)
   that is intended for people without any disability 
   who are operating under standard conditions." One thing I like
   about this definition is that the content's format doesn't 
   matter. Text can be primary content and a video can be 
   alternative content.


Correct. Though, in the corrected memo, I use the term "secondary content"
instead of "alternative content".


2) Distinguishing primary from alternative content sheds
   light on some (WCAG) requirements on authors. For example,
   I agree that there should not be a P1 requirement to
   provide a text equivalent for another (non-text) 


As noted above, in the corrected version of the memo ("Corrected!") I use
the contrast primary/secondary as opposed to primary/alternative. (The more
I think about the term "alternative" the more I am convinced that it means
many things to many people and that it is far to loaded a term to reclaim
and give a precise meaning....)

Actually there are cases in which one should provide a text equivalent for
"(non-text) equivalent" and my basic rule covers that situation. I would say
that it should not be a P1 requirement to provide a text equivalent for:

1. Text-Accessible Primary Content, i.e., text element (possibly including a
text equivalent) in primary content
2. Text-Accessible Secondary Content, i.e., text element (possibly including
a text equivalent) in secondary content
3. Text-Inaccessible Secondary Content, i.e., non-text element in secondary

Text equivalents are not necessary for cases 1 and 2 since the content is
already accessible. Text equivalents are not essential (Priority 1) in case
3 since the content is secondary content. However, it should be a P1
requirement to provide a text equivalent for:

4. Text-Inaccessible Primary Content, i.e., non-text element in primary

Suppose that the Web site is teaching the value of auditory description (an
auditory equivalent of the visual track of a movie or animation); thus the
auditory description is _intended_ to be presented to people without any
disability. The auditory description is a non-text element (and also happens
to be a non-text equivalent) and by current WCAG 1.0 checkpoint 1.1, a text
equivalent should be provided. Yet I say that the requirement (at the P1
level) to provide a text equivalent for an auditory description depends only
on whether the auditory description is primary or secondary content. If the
auditory description is intended for people without any disability it is
primary content, and a text equivalent of it needs to be provided. However,
most of the time, one should not be required to provide a distinct text
transcript (i.e., text equivalent) of it, since usually auditory
descriptions are secondary content (they are not intended for users without
any disability but are useful for people with blindness).

3) For reference, here's Eric's revised WCAG checkpoint 1.1:
    "Ensure that every non-text element that, 
     under standard conditions, would result in primary 
     content has a text equivalent [Priority 1]."

Comments and questions:

1) Are the only types of content primary and alternative?
   Your definitions suggest that this is the case. What
   is the default when there are no stylistic or semantic
   indications (in a spec or in metadata) to distinguish
   primary from alternative content? I think that in 
   the absence of style and semantic information, you 
   have to consider generic XML content either entirely
   primary or entirely alternative. Either case is 


As the definition of "content" suggests, there are many usages of the term
content. And even within one major meaning there seem to be facets.

Some of the major axes upon which content can differ include,
primary/secondary, text-accessible/text-inaccessible, important/unimportant,
etc. Yet other information cannot be easily expressed as dichotomous data.

Regarding "defaults", see in the corrected memo. I have added some possible
rules that would allow a user agent to determine whether content should be
assumed to be "primary" or "secondary" (instead of the term "alternative")
in the absence of an explicit indication.

In the case of XML, I think that that the construct of primary/secondary
content needs to be built in. I would think it important in designing
XML-based applications, especially those involving diverse media, to make
provisions for marking content as primary/secondary.

You alluded to yet finer distinctions about content. I will focus for a
moment on marking of equivalents and their equivalency targets. These
markings suggest a few finer distinctions.

Equivalents should be marked with info about:

1. URI for content 
2. URI for equivalency target
3. Type of Equivalent: [ regular text equivalent of classical multimedia
presentation = default | captions for classical multimedia presentation |
collated text transcript of classical multimedia presentation | etc.]
4. Priority for Equivalent: [ 1=default | 2 | 3 | NA ]
5. Reference Document for Priority: [ WCAG 1.0 = default | etc.]
6. Disability Status Profile For Which The Equivalent Is Suited [ Base on
general mapping between "Type of Equivalent" and Disability Status = default
| visual disabilities | hearing disabilities | etc. ]
7. Output Device Profile For Equivalent: [ Base on general mapping between
"Type of Equivalent" and "Output Device Type" = default | etc. ]
8. URI For Output Style for Equivalent [ Base on general mapping between
"Type of Equivalent" and "Output Style" = default | etc. ]

Equivalency targets should be marked with info about:

1. Presentation Type: [ infer from MIME type = default [?] | classical
multimedia | audio-only | visual-only | nonlinearizable table | image | etc.

Note. If one wishes to integrate internationalization issues into the
markup, these should also be added.


2) I have a problem with this reformulation of 1.1. Content is
   primary based (in part) on author's intention. Your 
   formulation of 1.1 suggests that content could become
   primary independently of the author's intention, just
   based on the user side conditions. If content that 
   started primary doesn't end up primary, what is it?
   If primary is established from the author's vantage 
   point, it sounds like it's either primary or it's not,
   independent of the user's operating conditions.


My reformulation of WCAG 1.0 checkpoint 1.1 was: ""Ensure that every
non-text element that, under standard conditions, would result in primary
content has a text equivalent [Priority 1]."

My revised (3 August 2000) reformulation of WCAG checkpoint 1.1: "Ensure
that every primary non-text element has a text equivalent. [Priority 1]".
This revision makes two changes of note. First, this revised version
corrects a bug by removing the phrase "under standard conditions". I had
overlooked the fact that the "under standard conditions" provision is
already an integral part of my definition of "primary content" and therefore
did not need to be part of checkpoint 1.1. ("Primary content. The general
definition of primary content is "content (meaning #1) that is intended for
people without any disability who are operating under standard conditions."
That is, primary content must allow users without any disability to obtain
the essential benefit of a Web-based product or service when used under
_standard conditions_.)  Second, this revision also answers the question
posed by Ian Jacobs as to whether, under my conception, content could become
"primary" based on user-side considerations. I think that the answer to that
question has to be "No". Specifically, I have concluded that, for the sake
of convenient implementation, most if not all "style" information needs to
be considered "disposable". Style (as opposed to "content") is something
that tends to be more under user control and must be considered irrelevant
in determining whether content is considered primary or secondary. 

The Need to Refine Our Definition of "Element". We need to discuss the
extent to which we are truly all talking about the same thing when we refer
to "element". I am not sure, for example, if the wide variety of things that
I mean when I refer to a "text element" or "non-text element" can actually
be pulled from a DOM2 representation. There is also the problem of how to
handle multiple text elements and non-text elements may be found in what
DOM2 considers a single glob.

The Concept of "Important" Elements. This idea of generating a list of
"important" element types (and therefore having some being designated as
"unimportant") is interesting. It could have implications several
checkpoints. For example, perhaps checkpoint 1.1 should read: "Ensure that
every important primary non-text element has a text equivalent. [Priority
1]" If some element is unimportant, how can it be a Priority 1 requirement
to do almost anything with it?

I think that the designation of "important" element further underscores that
need for a construct of "primary" (versus "secondary") content. A content
author needs to be able to declare virtually any element "primary", based on
whether it is important or essential for persons without any disability,
overriding, in effect, the "importance" level that is based merely on the
element type.


3) What about alternatives of alternatives? Suppose I
   use nested OBJECT elements in HTML to say "Include
   this video, or if not, this image, or if not this
   other image, or if not this text." Is the first
   image only an alternative? Or is it a primary in
   some other context (having two alternatives)?
   The author has intended the image to be an
   alternative (in some sense) and therefore would
   not be required to provide a text equivalent.
   There may be shades of primary. 
   Would that be confusing?

EH: I think that you mean "equivalents" instead of "alternatives" (which is
not a defined term!). 

In the case you cite, a user agent should recognize that, in the absence of
explicit markup to indicate that the image and text are primary content, the
image must be considered secondary content. I assume that it is reasonable
for the nesting relationship to be used to indicate that the image and text
are equivalents for the video. If this is the case, then in the absence of
explicit designation as either primary or secondary content, they should be
assumed to be secondary content. In summary, equivalents should be assumed
to be secondary content if not explicitly designated otherwise.

By the way, in my view, if the user agent recognizes both the image and the
text as equivalents for the video, then it should probably give
presentational priority to the text rather than to the image. Recall that
the video (assuming it is "classical multimedia") requires captions,
auditory descriptions, and collated text transcript. Also recall that except
for the temporary requirement for prerecorded auditory descriptions, WCAG
does not require any non-text equivalents. That means that the "image" is
non-required (gratuitous, optional) and is less essential that the text,
which presumably is a collated text transcript.


IJ: Basically, I would like to try to keep the notion of
primary content but I want it to only make sense from the
author's point of view. 

EH: I agree.


IJ: Does the model still work if 
primary content is always primary content and there's
no WCAG 1.1 requirement for text equivalents
for content that "results in primary content"? 

EH: OK to have primary content always primary content. 

I am not sure what you mean by "there's no WCAG 1.1 requirement for text
equivalents for content that "results in primary content"". I think that the
notion of primary content provides an essential clarification to checkpoint
1.1. Obviously, there would be plenty of instances in which there would be a
"requirement for text equivalents for content that "results in primary
content"", i.e., all cases in which the primary content contains non-text
elements that lack text equivalents.


IJ: In other words, the author has to provide a text equivalent for
any non-text primary content. Why does that break?

EH: This sentence does not seem to match your preceding sentence. I assume
that you mean that the "author has to provide a text equivalent for any
primary non-text content that lacks a text equivalent." That does not seem



The assumptions about standard conditions and available
technology are good ones, but can they be constrained
to the author's side and the author's determination
of what is primary content?


Yes. The author should be able to assign the primary/secondary status of
content. By the way, standard conditions need to specify availability of
compatible text-to-speech capabilities and text-to-braille capabilities if
they were called for by primary content. The system should also be able to
linearize tables based on markup and simple heuristics.



I don't think that the user agent should be required to 
recognize content as being primary, but the user agent
must be able to recognize alternatives; these are peer 
alternatives. Why should the user know what is primary
(notably when what is most important to the user may
not be primary to the author)? Does it benefit the
user in any way to know what's primary? 


I am not sure what you mean by "peer alternatives". Again, I think that the
term "alternatives" is undefined. (If someone thinks that they know what the
term "alternatives" might mean, I suggest that they present a definition to
the list.)

Unfortunately, the user agent will not be able to reliably recognize
equivalents in all cases. I agree that it should be a top priority for WCAG
to determine how to mark equivalents and their equivalency targets.

The advantage to the user of having something marked up as "primary", from
the user's point of view is that they know "I have right to know the meaning
of this primary content -- either directly or from an text-accessible
equivalent (or possibly a prerecorded auditory description if the
equivalency target is a multimedia presentation) -- not merely in a 'source
view', but in human understandable terms, in a way that is suited to my
disability. Furthermore, I have the benefit of knowing that, from the
author's point of view, this material marked as secondary content is
non-essential, except for equivalents that also happen to be equivalents
that are suited to my disability. Knowing what is primary and what is
secondary allows me to focus on essentials rather than constantly wading
through unnecessary clutter."

From the authors' point of view, they know that by designating "primary
content" they:
1. Have a reliable way of designating what the typical person without a
disability needs access to in order to obtain the essential benefit of the
2. Only need to develop equivalents for primary content, not for secondary
content, including most required equivalents. This is particularly important
for developers of specialized software exclusively for one disability group.
If the software is not intended for the "person without a disability" at
all, then virtually all content is "secondary content" and virtually all
equivalents become optional rather than required. 
3. Have a way of focusing people's attention on the most important content.
4. Have a way of "overriding" the "importance" assignments that W3C user
agent guidelines plans to attach to HTML elements.

It should be noted that defaults can be established that would allow user
agents to make educated guesses about what the author would have intended as
the proper primary/secondary designation from information such as: whether
the content is an equivalent or an equivalency target, whether the element
type is important or unimportant, whether the element is a text element or a
non-text element, etc. Conversely, if the language supported the designation
of primary/secondary, then the user agent could guess at some of the other
pieces of information if they happen to be missing. 

Finally, I think that nothing less than the primary/secondary distinction
will allow people to readily evaluate how well they are doing in providing
people with disabilities access that is comparable to people without
disabilities. Progress can actually become measurable. Ensuring
accessibility (at least at the Priority 1 level) becomes conceptually
simple, "Ensure access to primary content plus accessible equivalents for
inaccessible primary content." (Of course, how encompassing this statement
is depends on how encompassing one's definition of "content" is; yet the
statement is remarkably scalable and adaptable to different meanings of the
word "content".)



Your proposed checkpoint 2.1b for UAAG requires user
agents to "make avilable all primary content as well
as all W3C-required equivalents". Is there any need
to single out the primary content? 


I single out primary content because: (a) there are many people with
disabilities who would rely on primary content alone, (b) even those who use
primary content mostly as a supplement their use of secondary content still
need to be able to try to access the primary content if they desire, (c) the
Priority 1 requirement to "make available" content should not encompass
secondary content except for required equivalents. (Note: An author could
provide an equivalent that is not required by WCAG. It should not be a P1
requirement to make those available.)

The general philosophy is, "Don't make accessibility requirements that are
not necessary and if you do make requirements, don't assign a high priority
level (e.g., Priority 1) unless it is truly warranted."



[By the way, Dan Connolly has said that we blew it
by calling two pieces of content "equivalent" if 
their relationship is not symmetric. As Eric points out,
the equivalence relationship is often imperfect and 
one-directional. Would we be better off using a term like 
"text alternative" with the understanding that the
text alternative is supposed to fulfill the same 


To be sure, the "equivalent" relationship is logically unidirectional, i.e.,
the relationship between the equivalency target and the equivalent cannot be

There may possibly be a better term but I am confident that it would not be
helpful now to use the term "alternative". As I recall we discussed using
the term "alternative" instead of "equivalent." I am glad we did not go with
that. I still don't think we have a firm grasp of what we mean or should
mean by "alternative". I actually like the term equivalent, because it shows
that we are striving to provide equivalent (comparable) access for people
with disabilities (see definition of Equivalent).  

By the way, I would like to further banish the term "alternative" to yet
further reaches of obscurity by replacing the terms "regular
content"-versus-"alternative content" (found in my "Corrected!" memo) with
the new and hopefully more precise terms of "equivalency



I have to think more about all of this. I think
there are some very interesting points in your proposal,
but I'm having trouble with blurring the lines between
author's intent and the user environment.


I hope that the clarifications that I have offered will sharpen the line
between the author's intent and the user environment.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0183.html
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html


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, 3 August 2000 23:57:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:27 UTC