Re: "Content"-related Fixes (including checkpoint 2.1)

Hello,

My comments preceded by IJ:

"Hansen, Eric" wrote:
> 
> 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.

IJ: We have said "content, including equivalent alternatives" in the
past to ensure that people pay attention to this. While I agree that
technically it's not necessary, I think that it's helpful.
 
> 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").

IJ: I agree.
 
> 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.

IJ: I have problems with this if 2.1 is supposed to be through
    the user interface only. If we are talking about users with
    assistive technologies primarily, then access through the DOM
    is the preferred solution. Therefore, 2.1 is not primarily for users
    who rely on speech or braille. It is for users with disabilities
    of the UA's user interface.
 
> 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>

IJ: There's a little editorial glitch (s/content all content/all
content/).
    Otherwise, I'm ok with the 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.

IJ: Yes.
 
> 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>

IJ: We may be dropping the "human consumption" part, since apparently
    it does not make much of a difference.
 
> ==== 
> 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>

IJ: Ok.

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

IJ: I would say that "are not needed" is too strong a statement. I think
that it's one of the key pieces, though perhaps neither sufficient nor
necessarily, stricly speaking.
 
> 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>

IJ: Ok.

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 2 May 2000 11:37:52 UTC