Proposed resolution to Issue 142

Hello,

Issue 142 [1] is concerned with ambiguities about checkpoint 1.5,
which in the 15 January 2000 draft [2] reads:

<OLD>
1.5 Ensure that all messages to the user (e.g., informational messages,
    warnings, errors, etc.) are available through all output device APIs
    used by the user agent. Do not bypass the standard output APIs when
    rendering information (e.g., for reasons of speed, efficiency,
etc.).
    [Priority 1] 
</OLD>

At the 19 January teleconf [3], we discussed some of the ambiguities:

1) What really does "all output device APIs" include? Does that
   include an API for the printer? If a sound device is supported,
   does that mean that text messages must be available as a series
   of beeps?

2) The second sentence of the checkpoint emphasizes how the requirement
   of checkpoint 1.2 applies here: use the standard input and output
   device APIs.

I believe there are two goals for this checkpoint:

 Intention 1) For supported output devices, don't work around
              standard output APIs. I believe this goal
              is covered by checkpoint 1.2

 Intention 2) User agents must ensure that messages to 
              the user are available in redundant modes
             (text, speech, graphical). 

How does the second intention interact with other checkpoints?

1) Checkpoint 5.2 requires that UAs make available UI information 
   programmatically.

2) Checkpoint 9.1 requires notification of changes in content and
   the UI (or should be expressed that way). Messages to the user
   surely count as changes to the UI.

3) Checkpoint 9.1 does not address redundant forms of output. This
   is the purpose of 1.5. Note that checkpoint 1.1 talks about
   how device independence applies to other checkpoints, but checkpoint
   1.5 does not.

4) Checkpoint 5.6 requires (Priority 2) the user of conventions for
   UI design.

Therefore, I propose the following changes:

Proposal 1) Modify Checkpoint 1.5 to read:

         Ensure that the user interface provides information
         through redundant output channels.

             Note. For example, if a sound is used to indicate
                   a change to the user, provide that information
                   as text and graphical information as well.
                   Refer also to checkpoint 9.1

          I think it should also be noted that if the standard UI
          controls are accessible, then using standard UI controls
          will satisfy this checkpoint. 

Proposal 2) Move the second sentence of 1.5 to the note after 1.2

Proposal 3) Change checkpoint 9.1 from:

       <OLD>
           9.1 Provide information about user agent initiated content
and viewport
              changes through the user interface and through APIs
[Priority 1] 
       </OLD>

       to:

       <NEW>
           Notify the user of user agent initiated content changes.
       </NEW>

       We can remove the requirement "and through APIs" because
checkpoint
       5.4 covers it:

            Provide programmatic notification of changes to content and
user
            interface controls (including selection, content focus, and
user
            interface focus).

       That means that the new 9.1 would only be about notification
through
       the user interface, which is what Guideline 9 says: "Notify the
       user of content and viewport changes".
   
Other comments: 

My action item from [3] also suggested information in the Techniques
document about the varying degrees of importance in messages.
I'm not sure where that would fit in to this proposal.

 - Ian

[1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#142
[2] http://www.w3.org/WAI/UA/WD-UAAG-20000115
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0124.html
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783

Received on Thursday, 20 January 2000 13:06:27 UTC