"Primary Content", etc. - Corrected!

Date: 28 July 2000
To: UA List
From: Eric Hansen, ehansen@ets.org
Re: "Primary Content", etc. - Corrected!

This document supersedes memo "'Primary Content', etc." sent
27 July 2000 
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0178.html). I 
apologize for clogging people's email boxes
with such big documents. Replies should be sent to
ehansen@ets.org.

Rather than trying to mark in the body of this memo all the
areas of change, I am listing below the major changes and
the rationale for them. I should emphasize that none of the
changes alters the definition of "primary content" itself.

Change 1. Changed the usage of the term "alternative
content" more in keeping with common usage.

Rationale: In the 27 July memo, I used the term "alternative
content as a contrast to "primary content". However, I think
now that the term "alternative content" is better contrasted
to what I will now "regular content". This makes the usage
more in line with earlier usage. For example, in HTML, the
IMG element is the regular content and the value of the
"alt" attribute is the "alternative text".

Change 2. Use the term "secondary content" as a contrast to
"primary content".

Rationale: The terms "primary" and "secondary" seem to go
together better. And as noted in "Change 1", the term
"alternative content" is now being used as a contrast to
"regular content".

Change 3. Added definitions of "regular content" and
"alternative content".

These have been added to Part 1.

In addition and have made number of other small
improvements, including a rule set for inferring
primary/secondary content.

If people want a copy of the MS Word document comparison
between the 27 July memo and today's memo, they can contact
me directly.

====

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
"secondary content", "regular content", "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/SECONDARY CONTENT AND REGULAR/ALTERNATIVE
CONTENT

This part explains the two contrasts: (a) primary versus
secondary content and (b) regular versus alternative
content. Both contrasts seem essential in ensuring access to
information by people with disabilities that is _comparable_
to access by people without any disability. The first
contrast establishes what information people without any
disability are supposed to receive. The second contrast
identifies the resources that can be brought to bear for
people with disabilities. The first contrast is focused more
on people without any disability and the second constrast is
focused more on people with disabilities.

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_.
The term "primary content" is a contrast to the term
"secondary content". (See "secondary content".)

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 secondary. 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 (see later in
this memo) for determining how to handle cases in which
markup is at least partially missing.

====

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

New:

Secondary 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.]

====

Suggestion 1.3: Provide a definition of "regular content".

New:

Regular content. Main content or original content. The term
is a contrast to "alternative content" (e.g., equivalents)
provided to improve accessibility for people with
disabilities.

====

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

Alternative content. Content that is designed as an
accessible alternative to regular content. For example, in
HTML, the IMG element is the regular content and the value
of the "alt" attribute is the "alternative text".

====

Suggestion 1.5: Develop a rule set for user agents to use to
infer the primary/secondary distinction when information is
missing.

There will be occasions when information is missing
(certainly now in absence of full language support, and even
later when the W3C-recommended standards for markup are not
followed). I do not present here a full rule set but offer
the following to indicate the kinds of rules that could be
followed by user agents to infer the primary/secondary
distinction.

1. Assume that "elements" (including attributes of HTML
elements) that represent alternative content, such as the
value of the alt attribute in the IMG HTML element, are
secondary content unless otherwise marked.
2. Assume that "elements" (including attributes of HTML
elements) that represent regular content such as the image
file for the IMG HTML element, are primary content unless
otherwise marked.
3. Identify elements types that are nearly always
"decorative" as opposed to important and assume that they
will be used present "secondary content" unless otherwise
marked up.
4. Identify elements types that are nearly always essential
to all users and assume that they will be used to present
"primary content" unless otherwise marked.

====

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 second 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 secondary 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. Failure to provide the text
equivalents for secondary content should not making access
impossible (Priority 1) or even difficult (Priority
2)because it little if anything to contribute to the goal of
ensuring comparable access. (Recall that only primary
content is intended for people without any disability.
Therefore providing alternative content for secondary
content can offer little or no help.)

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 (including
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 reflect the
distinction between primary and secondary 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 support the distinctions between
primary and secondary content as well as the distinction and
association between regular and alternative content."

Comment 1:

Note that when I refer to primary or secondary 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 "secondary 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
secondary content may be beyond the minimal requirement.
This notion of variations in style resulting in something
being categorized as a primary or secondary content may
present some problems that I have not yet resolved.

====

PART 6: ASSOCIATING CONTENT WITH OTHER CONTENT

Suggestion 6-1: Recommend specifications for associating
pieces of content, especially regular and alternative
content.

HTML provides partial support for the distinction and
association between regular and alternative content (e.g.,
alt-text for images but not the captions, auditory
descriptions, and collated text transcripts for movies and
animations). Yet it does not provide language support for
the distinction between primary and secondary content, much
less the association between primary and secondary content.
Being able to (automatically) identify regular content
associated with alternative content and vice versa seems
essential. I am not sure that it is important to be able to
associate primary and secondary content with each other.

====

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/secondary
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/secondary status of
Web content elements, make available all primary content
available as well as all W3C-required alternative content.
[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.

Note 2. Note that I refer to "W3C-required" alternatives
content, since one could some instances, provide
alternatives that are not required.

====

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

The guideline documents express some allegiance to
understanding the "function" of content (see the definition
of "Equivalent"), but a critical part of a function is
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
alternative content (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) and 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. In that case a text equivalent
(e.g., text transcript) must be provided for that auditory
description because the auditory description is primary
content.

Benefit 1: Fits with regulatory emphasis on _comparability_
between people with disabilities and people without
disabilities. Although the WAI does not make policy for
governments or other organizations, it can facilitate
adoption by building in features into the guidelines that
focus on the issue of comparability. The distinction between
primary and secondary content facilitates implementing
systems that ensure comparability and assists in evaluating
claims of comparability.

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 Regular Content and Alternatives (e.g., Equivalents)

Please note that firming up the distinction between regular
and alternative content reinforces understanding of the
"unidirectionality" of relationship between the two pieces
of content in the "equivalency" relationship. That is, 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>

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Received on Friday, 28 July 2000 11:40:49 UTC