"Content"-related Fixes (including checkpoint 2.1)

Date: 2 May 2000
To: UA List
From: Eric G. Hansen
Re: "Content"-related Fixes (including checkpoint 2.1)
====
1. Fix checkpoint 2.1

Generally speaking, I agree with Ian's comments about Phill's comments and
Jon's comments. All reviewers made some very good points.

I have long felt uncomfortable about the ambiguity in the word "content",
but we need to make sure that the cure is not worse than the disease.

I think that what is missing from the discussion is something that I alluded
to in point 1 of an earlier memo
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0194.html).
Following is an excerpt:

"1. Clarify the need for outputting the entire content through at least
three modalities -- visually-displayed text, synthesized speech, and
Braille.

"It seems to me that the document needs to make clearer that a
UAAG-compliant User Agent that is accessing WCAG-compliant content will be
able to render all Web content through each of at least three modalities --
visually-displayed text, synthesized speech, and Braille -- subject, of
course, to the limitations the applicability provisions of UAAG."

I am now thinking that in the notes for checkpoint 2.1 is a good and
necessary place to put that. I think that without some statement along that
line, it the meaning of checkpoint 2.1 is likely to remain quite ambiguous.

I think that we need to go back to what should be the implications of
conforming to checkpoint 2.1 using content that is triple-A WCAG compliant.
I believe that the net effect would be that all content would be available
through each of at least three modalities -- visually-displayed text,
synthesized speech, and Braille. Of course, not every user agent would
provide all this capability and are "protected" by the applicability
provisions of UAAG. Not all content is available in every viewport, but the
UAAG should not require that. 

I don't think that we need to mention "equivalent alternatives for content"
because that is already part of the definition of "content" -- or should be
(see revision to definition of "content" in this document). Indeed, having
that phrase may just confuse things.

Note that in checkpoint 2.1 we are using the softer word "access" rather
than the word "accessible". I think that this probably makes sense because
not every content element is "accessible" (and that is why we require
"alternative content" or "equivalent alternatives"). 

Notice that I have coined a phrase "value of content" in Note 1. This term
is used instead of simply the word "content" which, by itself, would not be
accurate.

Given where we are, I suggest the following for checkpoint 2.1:

OLD:
2.1 Ensure that the user has access to all content, including equivalent
alternatives for content. [Priority 1] 
Refer to guideline 5 for more information about programmatic access to
content. 
Techniques for checkpoint 2.1 

NEW:

2.1 Ensure that the user has access to all content. [Priority 1] 

Note 1. Following this checkpoint means that individuals who rely on
visual-text-only, braille-only, synthesized-speech-only, as well individuals
who rely on certain media combinations (e.g., captions and auditory
descriptions for movies and animations) will obtain the value of content,
provided that the content author adhered to WCAG 1.0.

Note 2. Ordinarily, a "source" view does not adequately fulfill this
checkpoint.

Refer to guideline 5 for more information about programmatic access to
content. 
Techniques for checkpoint 2.1 


=======

2. Fix Definition of Views, Etc.

One problem is that the current definition implies that all content should
be available from every viewport. This need not be the case. I have changed
the last paragraph.

I have also re-noted a change mentioned in a earlier memo. That change
removes the word "content" from the sentence so as not add confusion to
meaning of the word content.

OLD:
Views, viewports, and current viewport 

User agents may handle different types of content: a markup language, sound,
video, etc. The user views rendered content through a viewport, which may be
a window, a frame, a piece of paper, a speaker, a virtual magnifying glass,
etc. A viewport may contain another viewport (e.g., nested frames).
Viewports do not include user interface controls that do not present
content, such as prompts, menus, alerts, etc. 

User agents may render the same content in a variety of ways; each rendering
is called a view. For instance, a user agent may allow users to view an
entire document or just a list of the document's headers. These are two
different views of the document. 

The view corresponds to how source information is rendered and the viewport
is where it is rendered. The viewport that contains both the current focus
and the current selection is called the current viewport. 

The current viewport is generally highlighted when several viewports
co-exist. 

A viewport may not give users access to all rendered content at once. In
this case, the user agent should provide a scrolling mechanism or advance
and rewind mechanism. 

NEW:

Views, viewports, and current viewport 

User agents may handle different types of content: a markup language, sound,
video, etc. The user views rendered content through a viewport, which may be
a window, a frame, a piece of paper, a speaker, a virtual magnifying glass,
etc. A viewport may contain another viewport (e.g., nested frames). 

<CHANGE>Viewports do not include user interface controls such as prompts,
menus, alerts, etc.</CHANGE *** Note that this change was already noted in
my previous memo:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0194.html>

User agents may render the same content in a variety of ways; each rendering
is called a view. For instance, a user agent may allow users to view an
entire document or just a list of the document's headers. These are two
different views of the document. 

The view corresponds to how source information is rendered and the viewport
is where it is rendered. The viewport that contains both the current focus
and the current selection is called the current viewport. The current
viewport is generally highlighted when several viewports co-exist.

<CHANGE>A user agent should provide mechanisms for accessing content all
content that can be presented by each viewport (e.g., scrolling mechanism,
advance and rewind). </CHANGE> 
====
3. Fix definition of "Content"

I have added a sentence at the end of the definition affirming that
equivalent alternatives and other accessibility information are also
"content".

If this change is made, one must check the other usages and make sure the
term is used consistently.

For your information, my enumeration of what I mean by "accessibility
information" is found in section 3 of my earlier memo
(http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0754.html). 

This section is based, in large part on my ruminations of was "content" is.

See my earlier memo
(http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0177.html) for
further rationale for changes. 

   3. Content

   <BLOCKQUOTE>
   In this specification, the term "content" refers to the
   document object. Some content is designed (by specification)
   for "human consumption". For an HTML document, this includes
   what appears between the start and end tags of elements, and
   the values of some attributes (e.g., alt, title, summary).
   Other content is meant for machines, including the markup
   itself (e.g,. element and attribute names), some attribute
   values (e.g., class, id, lang, src), style sheets, scripts,
   etc.
   </BLOCKQUOTE>

New (2 May) by Eric Hansen:

<BLOCKQUOTE>
In this specification, the "content" refers to the document object. Some
content is designed (by specification) for "human consumption". For an HTML
document, this typically includes what appears between the start and end
tags of elements, and the values of some attributes (e.g., alt, title,
summary). Other content is meant for machines, typically including the
markup itself (e.g,. element and attribute names), some attribute values
(e.g., class, id, lang, src), style sheets, scripts, etc. The term "content"
ordinarily encompasses equivalent alternatives and other accessibility
information.
</BLOCKQUOTE>

==== 
4. Fix definition of "Equivalent alternatives for content" per earlier memo.

This is important because it reaffirms the important notion that equivalent
alternatives are still "content". 

Excerpt from earlier memo:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0177.html

 4. Equivalent alternatives for content 


  <BLOCKQUOTE>
  Since <DEL>rendered</DEL> content in some forms is not always accessible
to users with disabilities, authors must specify equivalent alternatives for
content. 
  </BLOCKQUOTE>


Comment by Eric Hansen: Clarify that equivalent alternatives are not needed
for accessible content. Leave off the phrase for content, since that is part
of the definition.

New by Eric Hansen:

  4. Equivalent alternatives

<BLOCKQUOTE>
Since content in some forms is not always accessible to users with
disabilities, authors must provide equivalent alternatives for inaccessible
content. 
</BLOCKQUOTE>

====

<END OF MEMO>

===========================
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 Tuesday, 2 May 2000 11:17:54 UTC