- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 25 Jul 2000 16:37:32 -0400
- To: w3c-wai-ua@w3.org
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