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

Re: Comments/questions about checkpoint 9.3 (configuration of eventnotification)

From: Ian Jacobs <ij@w3.org>
Date: Wed, 26 Jul 2000 11:15:54 -0400
Message-ID: <397F00AA.BEE50EE@w3.org>
To: Charles McCathieNevile <charles@w3.org>
CC: w3c-wai-ua@w3.org
Charles McCathieNevile wrote:
> 
> An event that doesn't cause a change need not be notified - I am thinking
> about changes to the document (am I on the right tram here?).

Yes, that's true. But furthermore, an event that doesn't cause
a change in the UI need not be notified in the UI.
 
> A change to the UI may not be obvious to somebody using a serial access mode
> on a large document (50 characters opf braille doesn't give a very big
> picture of 90 lines of document. And the UA guidelines are a fair bit longer
> than 90 lines, as is the checklist.

My browser does not work this way: let's say a script causes a change
to something outside the viewport. I am not informed that there has
been a change to content outside the viewport. Are you asking that
changes to content outside a viewport be indicated to users with
disabilities? 

 - Ian
 
> Charles McCN
> 
> On Wed, 26 Jul 2000, Ian Jacobs wrote:
> 
>   Charles McCathieNevile wrote:
>   >
>   > 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.
> 
>   No. Here's why:
> 
>   1) Some events cause no change in the UI. For example, an executed
>   script
>      that does a calculation and changes content but does not change the
>   UI.
> 
>   2) Other events cause changes to the UI. Since those changes are obvious
>      to a user of the native UI, we don't require the UA to provide
>      redundant indication of the change in the UI.
> 
>   3) We require that all events be broadcast through an API.
> 
>   4) We make accessibility requirements on the UI, such as checkpoint
>      1.5, which requires that messages have text equivalents in the UI
>      that may be used by ATs.
> 
>   5) No, we are not requiring that ATs do anything.
> 
>     - Ian
> 
>   > 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-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
>   >
>   >
>   > --
>   > 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
> 
>   --
>   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

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Wednesday, 26 July 2000 11:16:06 GMT

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