Comments/questions about checkpoint 9.3 (configuration of event notification)

Hello,

In the 7 July Guidelines [1], checkpoint 9.3 (Priority 3) reads:

   Allow the user to configure notification preferences for 
   common types of content and viewport changes.
      Note: For example, allow the user to choose to be notified 
      (or not) that a script has been executed, that
      a new viewport has been opened, that a pulldown menu has
      been opened, that a new frame has received focus, etc. 

1) Since this checkpoint does not specify that it is about notification
   through an API (which is covered by checkpoint 5.5), our document
   says that this checkpoint refers to notification through the
   user interface. 

2) Looking back at the history of the checkpoint
   (checkpoint 10.2 was introduced in the 9 July 1999 draft [3]), I 
   believe that originally this requirement was supposed to apply to 
   notification through an API and notification through the UI. 
   Refer to 30 June 1999 discussion [4]. We dropped filters
   on the API notification at some point since applications can 
   filter out whatever they wish.

3) If notification is to be provided through the UI, then by
   default all events would have to be indicated to the user.
   How would that work in practice? We have to address that
   question before we discuss how filtering will work. 

4) If we try to identify a minimal set of events that are
   "common types of content and viewport changes", what 
   would be in that set? We could use the information
   in the Note after the checkpoint, but that list is
   short and two of them are covered by other checkpoints:

   a) a script has been executed
   b) a viewport has been opened (but control over viewport opening
      is covered by checkpoint 4.16).
   c) a pulldown menu has been opened. 
   d) a new frame has received focus (but control of focus 
      change is covered by checkpoint 4.15).

   I would note that checkpoint 1.5 already requires that messages
   from the UA have text equivalents in the UI.

5) The techniques document [2] talks about frame techniques but mostly
   disabling notification of changes (on an element basis, for css
properties,
   and for changing animations. In short, we don't have many techniques
   explaining what events should trigger notifications, nor how that
   information could be communicated to the user (e.g., through the
   status bar).

6) Who does notification through the UI benefit? For users with
   assistive technologies, we already require that all changes
   be sent through an API. What users using the UA's native
   UI benefit from notification of changes?

I'm looking for answers to these questions to figure out what
the minimal requirements for 9.3 are or whether we should delete it.
I realize that notification is very important, but we should flesh
this checkpoint out before we continue with it.

 - Ian

[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000707/
[2]
http://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20000707/#tech-configure-change-notification
[3] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990709/
[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0265.html
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 25 July 2000 16:37:36 UTC