"Primary Content", etc.

Date: 27 July 2000
To: UA List
From: Eric Hansen
Re: "Primary Content", etc.

At the 13 July telephone conference I took an assignment to explain my
proposal for a definition of "primary content."

I am also including other definitions that I am using in a paper that I am
writing. I think that they might be useful. This memo also introduces a
concept called "standard conditions" which I believe can greatly simplify
and clarify the meaning of the guidelines. Indeed, without such a concept, I
think that some of our checkpoints are not quite correct.

The very last part of this documents lists a few of the problems that these
changes are trying to address and lists a few benefits of making the
changes.

This memo has several objectives, listed below beginning with the most
important:

1. Set forth some definitions capable of reserving "namespace" for terms
such as "primary content" and "alternative content", "standard conditions",
"nonstandard conditions" in the WAI working groups and documents.

2. Make some changes in UAAG and WCAG documents, especially the definitions
and ancillary material. (I am not cross-posting this immediately.)

3. Set forth a piece of a vision or concept of accessibility and suggest how
that may help WAI set its course in the future. 

INTRODUCTION

I believe that the lack of solid definitions of "primary content" and
"alternative content" has adversely affected the previous two guideline
documents (Web Content and Authoring Tools) and that by not addressing it
now with the User Agent guidelines, we will be compounding the difficulties.

I realize that we will not be able to clear up everything all at once. There
are some clarifications that will have to await later iterations of all
three guidelines. But I believe that with the User Agent guidelines we still
have an opportunity to avoid some future trouble as well as to set a
positive direction for the future. 

PART 1: PRIMARY AND ALTERNATIVE CONTENT

Suggestions 1.1: Provide a definition of "primary content".

New:

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

Comment: 

The question arises: "_Who_ does the 'intending' referred to in the
definition and how is that intention become manifest?" I think that the Web
content author's claim is currently the most relevant piece of information
for determining whether elements should be considered primary versus
alternative. However, other criteria are also possible, including: What
content do people without any disability commonly access when using the Web
site, etc. User agents should rely on explicit markings when available and
when they are lacking they should follow a rule-set (in process) for
determining how to handle cases in which markup is at least partially
missing.

====

Suggestion 1.2: Provide a definition of "alternative content".

New:

Alternative content. All content (meaning #1) other than primary content.
See the definition "primary content." [This could be elaborated on that will
have to be done later.]

====

PART 2: STANDARD AND NONSTANDARD CONDITIONS

Suggestion 2.1: Define standard conditions.

New:

Standard Conditions

Standard conditions are those condition for content delivery allow a person
without any disability to gain the full benefit of typical content, in this
case, Web content. Standard conditions serve as a reference point for
delivery of content. Among the important conditions that are standard for
Web content are a computer capable of a wide range of visual and auditory
output and which relies on keyboard and a pointing device (mouse) for input.
Individuals with disabilities will often be able to receive Web content with
standard conditions but in some cases, non-standard conditions will be
required. The more that conditions diverge from the standard conditions, the
lower the number of checkpoints that may be applicable. (See the section on
Checkpoint Applicability.)

==

[For WCAG] In the context of the WCAG documents, the term "standard
conditions" refers to the following set of conditions of delivery of Web
content: [see list below]

[For UAAG] In the context of the UAAG documents, the term "standard
conditions" refers to the following set of conditions of delivery of Web
content: [see list below]

==

1. A color visual display monitor about 14 to 17 inches diagonal measurement
with a pixel resolution of at least X and palette of at least X colors. 
2. Visual display capabilities adequate for handling motion video with
audio, animation, and other graphical and sound elements.
2. Stereo two speakers for output capable of outputting prerecorded [??]
audio and synthesized speech [How about other sounds?].
3. A pointing device (e.g., mouse) and keyboard for input.
4. Quick response time for accessing information both from local storage
devices and via the Internet.
5. Operated by one person at a time seated in front of the display monitor.
6. Moderately quiet room.
7. Moderately good room illumination.
8. Unlimited time per session, though usually measured in minutes or hours.
9. [?] Computer properly handles WIMP [spell out] interface
10. [?] System compatibility with readily available commercial assistive
technology. [I don't think that this is essential but it may not hurt.]
11. [For WCAG but _not_ for UAAG] Availability of general-purpose graphical
user agents (e.g., Web browser and multimedia players).

Comment:

It is critical that these conditions represent common, but reasonably
positive conditions because primary content delivered under these conditions
represents that usage that _has to be matched for people with disabilities_.
To match a level of delivery quality much lower than this would sabotage the
guidelines. For example, suppose that the "standard conditions" for Web
content specified the use of a reduced capability device, such as a
small-screen text-only mobile device. Such a reduced capability device would
unduly lower the bar that had to be reached. 

Note that standard conditions would be different for another class of
technology (phone, television, radio, etc.). Furthermore, over time the
standard conditions for a given class of technology may need to be modified,
though these conditions should designed to last for several years.

Note that reference to standard conditions does not in any way limit the
manner or condition in which Web technology _can_ be used. It is merely to
establish a stable point of reference against which access for people with
disabilities can be compared.

====

Suggestion 2.2: Define "nonstandard conditions".

Nonstandard conditions

Conditions that vary significantly from standard conditions. [This could be
elaborated upon further but that will need to come later.]

====

PART 3: CONTENT

This section is very rough. It attempts to delineate a few definitions of
"content".

====
Suggestion 3.1: Refine the definition of "content".

Importance: Fairly important. It would be more important if I felt that I
really had it right. I think that I have some of it close to right.

Old (7 July 2000 UA doc):

Content 
In this specification, the term "content" is used in two ways: 
Content refers to the document object as a whole or in parts. Phrases such
as "content type", "text content", and "language of content" refer to this
usage. When used in this sense, the term content encompasses equivalent
alternatives. Refer also to the definition of rendered content. and other
accessibility information. 
Content refers to the content of an HTML or XML element, in the sense
employed by the XML 1.0 specification ([XML], section 3.1): "The text
between the start-tag and end-tag is called the element's content." Context
should indicate that the term content is being used in this sense. 

New:

Content:

The word content is used in several different ways in this document. [I have
not determined that the UA document itself uses the term in each of the
following ways.]

Content #1: The information and functionality that are available to the user
through the user interface.[This seems close to what we refer to as
"rendered content".] This meaning of content encompasses that which is
produced as a result of content #2, style, and logic [??] information. This
meaning focuses on that which is rendered. Note that this meaning includes
the notion of functionality.
 
Content #2: The elements that are used to produce content #1. This meaning
of content _includes_ style information. See checkpoint 2.1 (content
includes style information). See definition of element.
 
Content #3: Content as opposed to Style (Formatting) information.  

Content #4: Content as opposed to Functionality. This meaning of content is
contrasted to the "functionality". This contrast seems implicit in the use
of the term "content" is checkpoints themselves and the term "functionality"
in the section on applicability. [I am not sure that this distinction holds
up well.] 

Content #5: Value or benefit, such as of a product or service. Under this
definition, one wants to ensure that people with disabilities obtain the
full value or benefit of a Web-based product or service. [Note. This
definition should not be used in checkpoints.] Fake example: "The purpose of
the guidelines is to make Web content accessible to people with
disabilities." UA document example: "The guidelines in this document explain
to developers how to design user agents that are accessible to people with
disabilities. User agents include graphical desktop browsers, multimedia
players, text browsers, voice browsers, plug-ins, and other assistive
technologies that provide access to Web _content_." [Emphasis added].

Content #6: The message to be communicated by content meaning #1. Example:
"The goal of the guidelines is to make Web content accessible to people with
disabilities" is taken to mean that the message can be received and used by
people with disabilities.

[ETC.]

====

PART 4: ELEMENTS AND EQUIVALENTS

Suggestion 4.1: Define "element" as used in the context of text element and
non-text element.

Proposed Language:

Element. An element is a coherent parcel of Web content (content meaning #2)
intended for producing "information and functionality that are available to
the user through the user interface" (content meaning #1). An element may be
thought of a "pre-rendered content", since it refers to content that
"precedes" (i.e., is used to produce) what appears (visually, auditorily,
etc.) at the user interface. The term "pre-rendered" content is used instead
of "unrendered" content since rendered content can also be used for
generating content meaning #1. For example a parcel of visually displayed
text may properly be considered an element, since it could be read such as
by an optical character reader and translated into another form (e.g.,
Braille text, synthesized speech). [Need to determine whether elements can
contain other elements (?). Also whether elements are determined at the time
of authoring (?). Also whether certain kinds of content [certain media types
(??)], such as images, _must_ be regarded as elements, although one element
can include other elements. Also whether elements can be of any size, e.g.,
a single text character, a page, a presentation, or a whole Web site. Also
whether those elements presented to the person with a disability in order to
obtain the full benefit should have little or no irrelevant material.]

====

Suggestion 4.2: Define the term "text element".

The term text element is one of the most important terms in the document. As
I picture it, as noted later, a text equivalent is essentially a text
element that fulfills essentially the same function as some other content.

New:

Text Element

A "text element" is an element that has the accessibility and communication
advantages commonly associated with well-formed written text. Specifically,
a text element fulfills its function when delivered in any of the _core text
element output modes_ (visually-displayed text, synthesized speech, and
Braille) to their respective _core disability reference groups_. An
important characteristic of a text element is "seriality"; that is, a text
element must make sense when presented in serial fashion (i.e.,
sequentially), such as via audio or Braille. [Note. The foregoing might be
changed unless changed from "seriality" to "serializable" yet that would
assume a higher level of processing that I am not sure that we want to
assume/permit/require. THIS IN AN IMPORTANT ISSUE. Our position on that this
issue affects whether or not nonlinearizable tables should be considered
non-text elements. There is nothing that in my view theoretically requires
that candidate text elements require little or no processing. I suppose that
in order we specify a finite set of permissible file formats.] [I am not
sure whether I am sold on the following, but here is a rough cut:] In the
context of this document, a text element must be created so that any CSS
style information and HTML-type style [?] information found in candidate
text element is "disposable". Thus, loss of any such style information must
not cause the rendered text element to fail to fulfill its function.[Ian,
does this last sentence match what we discussed? The requirement to have
formatting information is not required by a theory (at least my theory) of
equivalents but may be justified on the basis of technical/pragmatic
issues.]

Comment 1:

At this time, I do not define a text element as necessarily conforming to
WCAG 1.0 checkpoint 14.1 ("Use the clearest and simplest language
appropriate for a site's content. [Priority 1]", though maybe it should. I
need to think more about this. Comments welcome.

Comment 2: 

Creating a text element almost invariably involves inserting text characters
(usually in written natural language such as English, French, etc.) for
storage, retrieval, and rendering; nevertheless any specific mechanism for
creating a text element is not an essential characteristic.

I believe that text elements must be logically distinct, even if they drawn
upon the same resource. Logical distinctness can then yield presentational
distinctness when necessary.

Comment 3

As I have indicated before, I believe that nonlinearizable (or [?]
nonserializable) tables (tables that cannot be automatically linearized)
should be considered a non-text element and there require a text equivalent
(i.e., linearized [or serialized] table). Comments welcome.

Comment 4

We need to talk more about what kind of "formatting" and processing
information it is permissible or required to provide with or as a part of
text elements.

====

Suggestion 4.3: Define "core text element output modes".

Each of these _core disability reference groups_ (blind, deaf, deaf-blind)
corresponds to a "core text output modalities is matched to a _core text
element output mode_: deaf: visually displayed text via the sense of sight,
blind: synthesized speech via the sense of hearing, and deaf-blind: Braille
for the tactile sense.

====

Suggestion 4.4: Define the term "disability reference groups".

New:

Disability Reference Groups 

Reference groups are those groups of people with disabilities that the
guidelines are intended to benefit. The WAI has not established a general
standard list of disability groups, although such a list might contain
groups such as [? blind, low vision (including color blind), deaf, hard of
hearing, deaf-blind, learning disability, physical disability]. However,
there are three _core disability reference groups_: blind, deaf, and
deaf-blind. These three groups represent disabilities that affected by
impairment to sight and hearing, which are the sensory modalities most
commonly used for communication of Web content. 

Comment 1

I think that it is justifiable and perhaps necessary to give special
emphasis to these core disability reference groups.

====

Suggestion 4.5: Define non-text element.

Non-Text Element

Conversely, a "non-text element" is an element that _lacks_ one or more of
the advantages of text elements. For example, it fails to preserve its
function (e.g., convey its message) when rendered in at least one of the
three core text element output modes -- visually displayed text, synthesized
speech, and Braille. 

Comment: Distinguishing Between Text Elements and Non-Text Elements

This comment describes how to distinguish between a text element and a
non-text element.

Creating a text element almost always involves inserting text characters
somewhere; however, one must avoid being confused into thinking that this
method of creating an element is a defining feature of text elements. Note
that the list of _non-text_ elements in WCAG checkpoint 1.1 contains things
that were created using _text_ characters, such as ascii art and scripts,
etc. For that matter, even audio and video files (or any other computer
data) can be construed as consisting of combinations of the _text
characters_ of "1" and "0".  

Additionally, the fact that something _appears visually as text_ does not
mean that it is a text element. For example, as emphasized in checkpoint 1.1
of WCAG 1.0, "graphical representations of text" are non-text elements.
Somewhat more surprisingly, _any visually displayed text_ is properly
regarded as a non-text element because, given ordinary commercially
available technology, the visually-displayed text fails to render sensibly
in at least one of three modalities -- visually-displayed text, synthesized
speech, and Braille. Any visually displayed text obviously has the quality
of being rendered as visually displayed text, yet at this time, it cannot be
rendered as synthesized speech or Braille without delivery mechanisms that
are not commonly available commercially. Some combination of technologies
might now exist (e.g., optical character recognition) that could read the
text from a visual display and then translate that into an electronic text
representation that could then output to synthesized speech and Braille (as
well as back into visually displayed text). Yet such a combination of
technologies is not commonly available commercially and is likely to be
quite inaccurate. Thus, requirement to provide a text equivalent depends not
merely on the presence of a non-text element; it depends on also on it
lacking a text equivalent. If the visually displayed text is rendered from
an underlying text representation (e.g., ordinary prose text between tags or
with other appropriate markup in an HTML file), then it already has a text
equivalent, whereas, if the visually displayed text is rendered from a
graphical image (i.e., a picture), then it lacks a text equivalent, and a
text equivalent must be provided.

====

Suggestion 4.5: Clarify the definitions of text equivalent and non-text
equivalent.

Proposed Language:

Text Equivalent. A text equivalent is a text element that is an equivalent
for some other content.

Non-text Equivalent. A non-text equivalent is a non-text element that is an
equivalent for other content. For example, an auditory description is an
auditory equivalent of the non-auditory track information (especially the
visual track).

Comment:

Note that a text equivalent may be created not only for primary content, for
any content ("some other content").

====

PART 5: CHECKPOINT 1.1 OF WCAG 1.0 

Overview: Split checkpoint 1.1 of WCAG 1.0 into three checkpoints and
include the concept of primary content.

Suggestion 5-1: Fix the main portion of WCAG 1.0 checkpoint 1.1.

Importance: Very important

Old:

"Provide a text equivalent for every non-text element..."

New checkpoint 1.1a:

"Ensure that every non-text element that, under standard conditions, would
result in primary content has a text equivalent [Priority 1]."

Comment 1:

This revised version makes clear that elements produce content meaning #1
(since the definition of primary content refers to meaning #1).

The use of "would" correctly confirms that the implication that they must
provide the text equivalent even if the content may be used under
nonstandard conditions.

Comment 2

Probably the most important kind of equivalent is the "text equivalent."
WCAG 1.0 requires Web content developers to provide text equivalents for all
non-text elements.  

Old WCAG 1.0 checkpoint 1.1 reads: 

	1.1 Provide a text equivalent for every non-text element (e.g., via
"alt", "longdesc", or in element content). This includes: images, graphical
representations of text (including symbols), image map regions, animations
(e.g., animated GIFs), applets and programmatic objects, ascii art, frames,
scripts, images used as list bullets, spacers, graphical buttons, sounds
(played with or without user interaction), stand-alone audio files, audio
tracks of video, and video. [Priority 1]

It should be noted that there are many cases of non-text element for which
it is not necessary to provide a text equivalent because a text equivalent
already exists, for example, visually displayed text that already has an
underlying text representation.

====

Suggestion 5-2: Fix the secondary part of WCAG 1.0 checkpoint 1.1.

New checkpoint 1.1b:

"Ensure that every non-text element that under standard conditions would
result in only alternative content has a text equivalent [Priority 3]."

Comment 1:

The Priority 3 designation for this proposed checkpoint makes sense because
having such text equivalents "may" help people with disabilities, but
failure to provide the text equivalents should not making access impossible
(Priority 1) or even difficult (Priority 2).

This says, for example, that if a Web content developer provides a sign
language video equivalent as alternative content for a written text, then it
is only a Priority 3 requirement to provide auditory descriptions, text
transcript (collated text transcript if there is audio), and captions (if
there is an auditory track). If, however, the sign language video is primary
content such as would probably be the case if the purpose of the material
was to teach sign language skills to general audiences (i.e., persons
without any disability), then those equivalents must be provided per
checkpoint 1.1a (Priority 1).

====

Suggestion 5-3: Explain why the current WAI documents don't fully reflect
this distinction between primary and alternative content.

New:

"Current versions of the WAI documents do not fully reflect the distinction
between primary and alternative content because they tend to reflect what
was possible in HTML versions 4.0 or earlier. Those languages do not provide
a standardized way for the Web content author to make a claim about what
claim about which content is "primary" and which is "alternative". Future
Web languages and customizable langauges (XML) should allow elements to be
marked up to indicate whether elements will be used to produce primary
content (i.e., content [meaning #1] to be used by people without any
disability)."

Comment 1:

Note that when I refer to primary or alternative content, I am using a
definition of content (meaning #1) that may include the concept of style or
formatting.

It may be important for some applications (high stakes educational testing)
to be able to specify ranges or enumerated settings that are to be
considered "primary content" and those outside that range or enumerated set
to be considered "alternative content". For example one can imagine a high
stakes educational test in which a certain set of font sizes are considered
as producing primary content (e.g., 6 point to 48 point) versus alternative
content (e.g., smaller than 6 point or larger than 48 point). However, for
most applications, this level of refinement over the distinction between
primary and alternative content may be beyond the minimal requirement. This
notion of variations in style resulting in something being categorized as a
primary or alternative content may present some problems that I have not yet
resolved.

====

PART 6: ASSOCIATING PRIMARY AND SECONDARY CONTENT

Suggestion 6-1: Provide specifications for associating primary and
alternative content.

[More needs to be said on this point.]

====

PART 7: FIXES TO UAAG CHECKPOINT 2.1, ETC.

Suggestion 7.1: Split UAAG checkpoint 2.1 into three checkpoints.

Old (UAAG 7 July 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.
Refer to guideline 5 for more information about programmatic access to
content. 
Techniques for checkpoint 2.1

New checkpoint 2.1a:

2.1a Until there are W3C-recommended ways for the Web content author to make
claims about the primary/alternative status of Web content elements, make
all content available through the user interface. [Priority 1]

Note. In some cases, making content available may consist merely of
providing a document view. 

Comment

For checkpoint 2.1a, one still needs to have applicability kick in
sometimes.

I am still uncomfortable with this checkpoint because there is no way to
ensure or require that content is understandable by humans.

====

Suggestion 7.2: Ensure Priority 1 access to primary content and required
alternatives.

New checkpoint 2.1b:

When there are W3C-recommended ways for the Web content author to make
claims about the primary/alternative status of Web content elements, make
available all primary content available as well as all W3C-required
equivalents. [Priority 1]

Comment:

Note 1. Since not every device can deliver every kind of primary/alternative
content, the user agent applicability provisions may kick in.

====

Suggestion 7.3: Ensure Priority 3 access to "other" content.

New checkpoint 2.1c:

When there are W3C-recommended ways for the Web content author to make
claims about the primary/alternative status of Web content elements, make
available all other content beyond that covered in checkpoint 2.1b.
[Priority 3]

Note. This "other content" would include non-required alternative content
(e.g., equivalents not required by WCAG).

====

Suggestion 7.4: Require that user agents provide a minimum set of
accessibility modes.

Either as a UAAG checkpoint (e.g., checkpoint 2.3) or techniques for it,
specify expectations for different modes of presenting content.

New:

"Provide customizable presentation modes suited to different disability
profiles. [Priority 2 (or 3)]"

"Techniques"
Following are possible modes.

"1. BL Mode - optimized for individuals who are blind. Provide primary
content plus facilitated access to auditory descriptions, synthesized speech
renderings of text elements, font modification features, etc."
2. DF Mode - optimized for individuals who are deaf. Provide primary content
and text equivalents for auditory information (e.g., captions).
3. DB Mode - optimized for individuals who are deaf-blind. Provide primary
content [?] plus facilitated visual and Braille access to all text elements,
including text equivalents for inaccessible primary content. Facilitate
configuration and control for turning visual content on and off.
4. Full Access Mode - provide primary content plus menu (or other) access to
all required equivalents.
[etc.]
5. Primary-Content-Only Mode - This mode is used to test the functionality
of an application vis-à-vis persons without any disability. This mode
provides a reference point for evaluating basic functionality of the
application and a point of comparison for evaluating access for people
_with_ disabilities.

====

Suggestion 7.5: Review UAAG the section on applicability.

The section on applicability needs to be reviewed. My hunch is that the
section could be considerably shortened and simplified through the use of
concepts such as "primary content" and "standard conditions".

PART 8: PROBLEMS AND BENEFITS

This section outlines a few of the problems that the changes try to address
and some of the problems. 

The problems and solutions have not been organized into a highly ordered
sequence. This is somewhat of a mixed bag.

Problem 1: Inability to Distinguish Between Essential and Non-essential
Content

The current guidelines do not generally distinguish between essential and
non-essential content in determining the accessibility requirements. Issue
299(Definitive list of important elements for known markup languages?
(http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#299) is one
manifestation of this problem.

Problem 2: Failure to See The WAI Documents as Minimal Requirements

I think that we need to be more explicit in the WAI document about the fact
that they are statements of minimal requirements -- not statements of an
"ideal" level of accessibility.

I think that we realize that we don't really know what the ideal level looks
like, and even if we did, it would be technically and otherwise impossible
to implement at this time.

====

Problem 3: An Endless Development Loop

Our current approach appears to require alternative content for all content,
which results in an endless loop. (I don't think that it was intended.) For
example, under the current phrasing, WCAG checkpoint 1.1 ("Provide a text
equivalent for every non-text element...") may put the Web content developer
into an endless development loop. Suppose that we have multimedia
presentation (mmp1). We need to provide auditory descriptions (synchronized
with the auditory track), captions (visually-displayed-text equivalent that
is synchronized with the visual/auditory tracks), and a collated text
transcript capable of being output visually, auditorily, and tactilely (via
Braille). Yet when we play mmp1 with some combination of auditory
descriptions, captions, and collated text transcript, that constitutes
another multimedia presentation which we will call simply "mmp2" (actually
it may constitute even more than one multimedia presentation). Now because
mmp2 is a multimedia presentation, it needs auditory descriptions, captions,
and collated text transcript, which are more complicated than those of mmp1,
since, for example, the audio is more complicated due to auditory
descriptions and the visual track is more complex due to captions. The
process continues to mmp3 an so on _ad infinitum_.

One obvious way to prevent getting caught in such an endless loop is to
clarify by saying that Web content developers _only_ have to develop
accessible "alternative content" for "primary content" that is inaccessible.


Problem 2: Failure to acknowledge or respect the content author's _intent_
in determining whether content is considered "primary" or "alternative".

The guideline documents express some allegiance to understanding the
"function" of content (see the definition of "Equivalent"), but fails to
acknowledge the important role of the _Web content author_ in designating
the function of content. For example, at a minimum, the Web content author
ought to be able to designate whether a specific content element will serve
to produce "primary content" or "alternative content". My criticism may seem
nonsensical since, for example, one assumes that "alt-text" for images is
intended by the content author to be "alternative content". But that is only
an assumption.

Yet, let us consider an example in which that assumption is incorrect.
Suppose that the Web content author has developed an instructional module
that teaches the role of various accessibility-related elements (prerecorded
auditory descriptions, renditions of text equivalents, renditions of
linearized tables, etc.). The developer wants to show examples of each of
the elements and he wants the examples to be available for all users (both
with and without disabilities). In this case he should be able to show
accessibility elements (e.g., visually displayed "alt-text", visually
displayed longdesc file contents, prerecorded auditory descriptions,
captions, visually displayed collated text transcripts, etc.) and designate
them as _primary content_. Under my proposed definitions, any of these that
are non-text elements (meaning that they _cannot_ be sensibly rendered as
visually displayed text, synthesized speech, and Braille) must have a text
equivalent provided since they are primary content. Almost all of these
probably already have text equivalents and so do not need them added. But
let us assume that the auditory description lacks a text equivalent and a
text equivalent (e.g., text transcript) must be provided. 

Unfortunately, there is no standardized machine-readable way for a Web
content author to make a claim about which content is "primary" and which is
"alternative". Sometimes I wonder whether the current WAI guideline
documents tend to incorrectly assume that the key to the distinction between
primary and alternative content lies in component type (e.g., primary =
multimedia presentation; alternative = captions, auditory descriptions,
collated text transcript) rather than in the specific communication purposes
of content, for which the stated intent of the Web content author would be a
highly relevant clue.

Benefit 1: Fits with regulatory emphasis on comparability between people
with disabilities and people without disabilities.

Benefit 2: Fits with definition of Equivalent.

Please note that this definition fits perfectly with the definition of
"equivalent" in WCAG 1.0, which also uses persons without any disability as
a reference point:

Content is equivalent to other content when both fulfill essentially the
same function or purpose upon presentation to the user. 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_. (from the definition
of Equivalent, emphasis added)

I would point out that there is a huge benefit it the conceptual simplicity
of having two important terms -- "equivalent" and "primary content" --
clearly linked in this way. Conversely, I think that failure to link the
terms in such a clear way injects "noise" into the conceptual framework.

Benefit 3: Reinforces the Unidirectional Relationship Between "Original"
Content and Its Equivalents

Please note that the distinction between primary and alternative content
builds upon and reinforces the "unidirectional" relationships between the
two pieces of content in the "equivalency" relationship. In most situations,
the original content will be primary content (i.e., for people without any
disability) and the equivalents will be alternative content (i.e., for
people with a disability). It is important to keep in mind that if content A
is an equivalent for content B, then that does not necessary mean that
content B is an equivalent for content B. (If I am correct, cases in which
the relationship would be true in both directions are generally trivial or
very rare.)

SUMMARY OF BENEFITS

I believe that adopting the main suggestion this memo will significantly
improve the quality of the WAI guidelines documents. I think that it can
make the checkpoints clearer and more easily understood and followed, will
prevent implementation problems that will otherwise arise, and very
importantly, will make the guidelines more readily applicable to different
languages, devices, and disability groups.

<END OF MEMO>

Received on Thursday, 27 July 2000 13:57:55 UTC