W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2000

Re: Proposed clarification of Checkpoint 1.5

From: Ian Jacobs <ij@w3.org>
Date: Mon, 28 Feb 2000 19:12:41 -0500
Message-ID: <38BB0EF9.5C676303@w3.org>
To: w3c-wai-ua@w3.org
Ian Jacobs wrote:
> 
> Hello,
> 
> Issue 195 [1] states that reviewers of the Candidate Recommendation [2]
> had difficulties understanding the wording of checkpoint 1.5:
> 
> <BLOCKQUOTE>
> 1.5 Ensure that the user interface provides information through
> redundant output modes. [Priority 1] 
> </BLOCKQUOTE>

Working group comments to my previous proposal suggest that we
need to reach a common understanding of the purpose of this 
checkpoint before a rewrite will help. Here are pieces of
my understanding of the requirement intended for 1.5:

1) We are expressing a user-interface requirement, not a programmatic
   access requirement. Checkpoint 5.2 already requires programmatic
   access to user interface controls.

2) I don't think 1.5 is meant to require a text equivalent for each
   message to the user. I think that text is a useful technique that
   enables different output modalities. Note that programmatic access 
   to UI controls is covered by checkpoint 5.2

3) I don't think that the requirement is for a user agent to provide
   a user interface controls, say, both graphically and through audio
   (but not speech if speech is not supported).

So what is this requirement supposed to say? A previous incarnation
of the checkpoint (from the Last Call draft
http://www.w3.org/TR/1999/WD-WAI-USERAGENT-19991105/) suggests that
it's really about messages through the UI:

<LAST CALL>
      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.
</LAST CALL>

How about this:

<NEW PROPOSAL>
      1.5 Ensure that user agent-initiated messages to the user 
         (e.g., informational messages, warnings, error messages, etc.) 
         are available through all output channels supported by the user 
         interface.
</NEW PROPOSAL>

Notes:
 0) I'd rather not talk about output device API.
 1) Applicability still applies here. 
 2) I've limited the scope slightly (perhaps uselessly) to those
    messages initiated by the user agent. I'm not particularly wedded
    to that bit of the proposal.
 3) The note afterwards would be the same as the one below in the
    OLD PROPOSAL.

 - Ian

[1] http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#195
[2] http://www.w3.org/TR/2000/CR-UAAG10-20000128

<OLD PROPOSAL>
 
> Therefore I propose this clarification:
> 
> <BLOCKQUOTE>
>   1.5 Ensure that the user interface presents information through
>       more than one output mechanism.
> 
>   (Note afterwards):
>       For example, alert the user to an event with a graphical
>       cue, and an audio cue, and a text message on the status bar.
>       Refer also to checkpoint 5.4.
> </BLOCKQUOTE>
> 
> Also, we can add to the techniques document that the user may want
> to configure the output modes.

</OLD PROPOSAL>

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814 or 212 532-4767
Cell:                        +1 917 450-8783
Received on Monday, 28 February 2000 19:12:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:52 GMT