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

Tis is not quite true - we can rewquire that the windows be left unlocked if
that is a requirement. For an AT that builds an off-screen model, that may be
an issue, as I noted recently with my emacspeak example. Or if it is not a
requirement then we should make it clear that we are going down a particular
path, and why.

Charles

On Wed, 26 Jul 2000, Denis Anson wrote:

  I don't think we can make any "requirements" to the AT vendors.  That's
  beyond our scope.  We have to make sure that the UA has an accessible path
  that meets the needs of the person with a disability, but we can't say that
  that is the only way to gain access.
  
  We can require a ramp to the door, but we can't keep people from climbing in
  the windows.
  
  Denis Anson
  
  -----Original Message-----
  From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
  Behalf Of Charles McCathieNevile
  Sent: Wednesday, July 26, 2000 2:14 AM
  To: Ian Jacobs
  Cc: w3c-wai-ua@w3.org
  Subject: Re: Comments/questions about checkpoint 9.3 (configuration of
  event notification)
  
  
  I guess there is still an important issue of whether we require AT to access
  through an API. (Rich, I'm fishing for comment here <grin/>). If not, then
  producing the content through the UI is how the user is going to find out
  what happened. I thought we had a seperate checkpoint that required taht,
  adn
  the configuration was to allow the user to turn that off.
  
  Charles MCN
  
  On Tue, 25 Jul 2000, Ian Jacobs wrote:
  
    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-not
  ification
    [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
  
  
  --
  Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134
  136
  W3C Web Accessibility Initiative                      http://www.w3.org/WAI
  Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
  Postal: GPO Box 2476V, Melbourne 3001,  Australia
  
  

--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia

Received on Wednesday, 26 July 2000 09:42:05 UTC