Checkpoints 7.5, 2.5, 2.6, 1.5, 3.8

To: UA List
From: Eric Hansen
Re: Checkpoints 7.5, 2.5, 2.6, 1.5, 3.8

This memo concerns Ian's memo [2] (Re: Proposal for 7.5 [Was Re: Issue with
checkpoint 7.5 (search) and serial...) and relates to other memos.

Suggestion 1: Refine terms or avoid them.

I have no problem defining the term "text" by itself as you have indicated,
but I think that the special meanings of the terms "text element" and
"non-text element" should be preserved. 

Other terms, with potentially special meanings, such as "text content" and
"non-text content" need to be examined for this kind of problem. For
example, when we refer to terms like "non-text content" the reader needs to
whether we are referring to:

(a) unrendered content that is _not_ composed of text characters (arguably
there is hardly anything that fits this category) 
(b) visually-rendered content that is _not_ composed of text characters
(this is a problematic category since such content could be either the
result of text elements or non-text elements)
(c) pre-rendering content composed of "non-text elements" which, per WCAG
checkpoint 1.1. require a text equivalent (this seems to be the most valid
definition, if we wish to use the term 'non-text content').

By the way, in early 1999 discussion with WCAG I did try to avoid some of
the ambiguity by further qualifying the terms that we now know as 'non-text
element' (used in WCAG 1.0) and 'text element' (not used in WCAG 1.0). I
tried to use terms that would point out their special meanings.
Specifically, I suggested the use of the terms:

a. "text communication element" rather than "text element"
b. "non-text communication element" rather than "non-text element"

See Bug-2 in [1] for reference to the terms "communication element".

Basically, I would like avoid using terms like "non-text content" unless
there is agreement on the definition.
====

Suggestion 2: Refine checkpoint 7.5.

As for your revised wording for checkpoint 7.5, it seems to be OK but might
bear some refinement.

IJ: 
> Proposal, based on Eric's text:
> 
> <NEW BY IAN>
> 7.5 Allow the user to search through text that has been rendered. 
>     The search must encompass all text within the
>     viewport, both inside and outside the point of regard. Allow the 
>     user to start a forward search from a location in content 
> selected 
>     or focused by the user. After a match, allow searching from 
>     location of the match. Provide a case-insensitive search option 
>     when applicable to the natural language of text. [Priority 2]

A further refinement might be to delimit this to visually-displayed text
since it is hard to see requiring this (as a minimum requirement) for
anything more. Thus (NEW by EH): "7.5 Allow the user to search through text
that has been rendered VISUALLY...."

New:

7.5 Allow the user to search through text that has been rendered visually.
The search must encompass all text within the viewport, both inside and
outside the point of regard. Allow the user to start a forward search from a
location in content selected or focused by the user. After a match, allow
searching from location of the match. Provide a case-insensitive search
option when applicable to the natural language of text. [Priority 2]"

Comment 1:

I focus on visual rendering since we don't expect them to be able to search
an audio file. Someone would need to use assistive technology if they needed
some kind text-to-speech output.

====

Suggestion 3: Clarify the meanings of checkpoints 2.5 and 2.6.

It looks like in checkpoints 2.5 and 2.6 when we refer to "non-text content"
we mean "non-text elements", i.e., content that would require text
equivalents per WCAG checkpoint 1.1. Please correct me if I am wrong in this
assumption. I am thinking that since we use the term "recognized" in front
of "text equivalent", one should also put "recognized" in front of "non-text
content" because there are lots of cases in which the system might not
recognize non-text content (elements). Current markup specs do not allow
identification of all non-text elements.  

Old:

"2.5 For non-text content that has no recognized text equivalent, allow
configuration to generate repair text. If the non-text content is included
by URI reference, base the repair text on the URI reference and content type
of the Web resource. Otherwise, base the repair text on the name of the
element including the non-text content. [Priority 2] 
Note: Some markup languages (such as HTML 4 [HTML4] and SMIL 1.0 [SMIL]
require the author to provide text equivalents for some content. When they
don't, the user agent is required to repair the invalid content by
generating a text equivalent. Refer also to checkpoint 2.6. 
Techniques for checkpoint 2.5 
"2.6 When the author has specified an empty text equivalent for non-text
content, do not generate one. [Priority 3] 
Note: Authors may provide an empty text equivalent (e.g., alt="") when one
is required by specification, but the non-text content has no other function
than pure decoration. Please refer to the Web Content Accessibility
Guidelines 1.0 [WCAG10] for more details. Refer also to checkpoint 2.5. 
Techniques for checkpoint 2.6"

New: No change suggested if my assumption about "non-text content" is
correct.
====

Suggestion 4: Fix checkpoint 1.5.

In connection with checkpoint 1.5, I have a general concern as to whether
this (and perhaps other checkpoints) that might be intended to cover things
that are presented to the user but which are _not_ derived from the document
object. To the point, do "messages" constitute something that might not be
included within the DOM? Is there any ambiguity about whether or not they
are part of the DOM? Is the emphasis of checkpoint 1.5 on addressing
'content' that is not part of the DOM or is it on how to present a special
class of information ("messages") that are part of the DOM? (By the way, if
implementing the W3C DOM is a Priority 1 checkpoint, is there really any
need or point to refer to some other lesser form of 'document object'?) 

The following change assumes that such messages are not part of the DOM and
that that is the reason that they are treated specially.

Old (18 August 2000):

"1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.)
that is part of the user agent's user interface also has a text equivalent
in the user interface. This text equivalent must be available to assistive
technologies through an API. [Priority 1] 
Note: For example, if the user is notified of an event by an auditory cue, a
text equivalent in the status bar would satisfy this checkpoint. Using
accessible standard interface controls (per checkpoint 5.8) should make text
equivalents available to assistive technologies for rendering as synthesized
speech or Braille. Refer also to checkpoint 5.5. 
Techniques for checkpoint 1.5"

New 1:

"1.5 Ensure that each message to the user (e.g., prompt, alert,
notification, etc.) has a text equivalent that is available through an API
and allow the user configure how to render classes of message through the
user interface [Priority 1]"
"Note. For messages rendered from text elements, the text element
constitutes a text equivalent. For messages already rendered from non-text
elements, a text equivalent must be provided."

Comment 1:

This version of the checkpoint probably needs to be made more specific
(i.e., what type of configurability).

Comment 2:

This version does away with the user of the term "non-text content" because
it does not seem necessary. 

Comment 3:

This change assumes that the user should be able to configure how prompts,
alerts, and notifications are handled. I can imagine that in systems
providing both text and sound, a user will not want to see some of these
classes of information. Some people will want to both see and hear messages
(perhaps being able to decide by the class of message). Some will want to
only see the messages and some will want to be able to only hear the
messages. The 18 August version seems to indicate that if the user agent is
operating in a text-only environment, the user will not have a choice about
whether those messages are presented visually or not. That seems inflexible.

====

Suggestion 5: Consider including different kinds of content in checkpoint
1.5.

I hope that I am not barking up the wrong tree (adopting a useless
strategy), but if checkpoint 1.5 is really supposed to address material
presented the user that does _not_ originate from the DOM, then perhaps the
checkpoint needs to be expanded to read something like the following:

New 2:

"1.5 Ensure that all information intended for the user (e.g., prompt, alert,
notification, etc.) that does not derive from the DOM has a text equivalent
that is available through an API and allow the user configure how to render
classes of information through the user interface [Priority 1]"
"Note. For information rendered from text elements, the text element
constitutes a text equivalent. For messages already rendered from non-text
elements, a text equivalent must be provided."

Comment 1:

The foregoing is probably too long for one checkpoint, but I think that it
conveys the idea. We don't want user agent developers to fail to provide
text equivalents for non-text elements that are produced from some source
other than the DOM.

Comment 2:

Repair text per checkpoint 2.5 is one class of content that does not appear
to derive from the DOM.

====

Suggestion 6: Fix checkpoint 3.8.

Following is an attempt to further clarify checkpoint 3.8.


Old (18 August 2000):

3.8 Allow configuration so that author-specified content refreshes do not
change content automatically. Allow the user to access the new content
manually (e.g., by activating a button or following a link). Advise the user
to refresh content according to the same schedule as the automatic refresh,
and indicate when the user has not yet refreshed content. [Priority 2] 
Techniques for checkpoint 3.8

New:

3.8 Allow configuration so that author-specified content refreshes do not
change content automatically. Allow the user to access the new content
manually (e.g., by activating a button or following a link). Advise the user
to refresh content according to the same schedule as the automatic refresh,
and if automatic refresh is on, indicate when the user has not refreshed the
content since the latest automatic refresh time. [Priority 2] 
Techniques for checkpoint 3.8

Comment 1:

I wonder if an "indication" is like an "alert" or "notification" but less
important. Does an alert, notification, or prompt have actual "content", but
an "indication" can be stylistic and therefore disposable? We probably need
to indicate what we mean by "indicate".

====

Suggestion 7: Explain what you mean by "glyphs".



[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/1999AprJun/0006.html

[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0304.html


===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090

Received on Monday, 28 August 2000 18:23:04 UTC