Re: DOM events Re: PROPOSAL: User Agent Issue 190:

A user agent defines the user interface (or at least as far as the DOM is
concerned.) So the user agent should be where the default activation is
determined. Because a user agent may be driven with an assitive technology,
it may well need to further abstract what it uses to fire the events.

I think the long term (PF) goal is to have a method for asking an element
what type of things it can activate. This is sort of like a context menu that
is available in many GUI systems.

But there is also an existing problem of access to existing markup written in
HTML. In order to deal with that, there needs to be a way for user agents to
provide access to the functionality. And I have suggested a technique for
doing that which loks forward to the kind of model we might expect a
beneficial future to bring.

Actually I think the ability to find out what fired the activation (in terms
of a device) is a bad idea, just like looking at the bit of memory that is
changed whenever the C key is pressed is a bad idea when there is a standard
API defined for getting a "c" input. However I think that it is important to
have multiple activation methods available for an element (although it may be
a two step process, just like the right click is today, in some
implementations).

Charles McCN

On Tue, 15 Feb 2000 schwer@us.ibm.com wrote:

  
  
  
  Charles,
  
  One of the things I brought up at the WAI-PF FTF was a need to determine
  the list of accessible actions mapped for a given element. That said, we
  should not need to fire a specific event to activate them. We simply need
  to activate them. For example, if a mouseover drops a menu item from
  JavaScript there should be an action in the list of actions you mention
  that describes the action and a method that enables you to activate it.
  This would also help with AccessKeys. AccessKeys could key off the method
  to give an item focus by default, the first activation mechanism possibly
  and then the rest of a set of method(s) that would allow you to selectively
  activate the function you want. The combination makes AccessKeys much more
  powerful.
  
  Today, in DOM 2, we have an DOMOnActivate event which would be fired on
  activation. I would much rather find out what function was activated as
  opposed to the device specific activation notification like onclick.
  
  Does this make sense?
  
  So, what we could have are these which is in line with alot of what you are
  saying:
  
  DOMOnFocusIn ( in DOM 2 - Merger of onMouseOver, onFocus)
  DOMOnFocusOut (in DOM 2 - Merger of onMouseOut, onBlur)
  DOMOnActivate (in DOM 2 - with a parameter indicating which method was
  triggered or is to be triggered) We may desire pre and post notification.
  
  DOMOnPointerMove (new - replaces onMouseMove)
  
  DOMSelectionChange (new - for SelectionModel)
  
  Regarding the above, would there be any reason to add event filter
  capability?
  
  Another consideration we should discuss is should we have a "default"
  activation method.
  
  Also, should a DOM element have a method to indicate if actions are mapped
  to the element?
  
  Good stuff Charles. Thanks for bringing this up again.
  
  Rich
  
  Rich Schwerdtfeger
  Lead Architect, IBM Special Needs Systems
  EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm
  
  "Two roads diverged in a wood, and I -
  I took the one less traveled by, and that has made all the difference.",
  Frost
  
  
  Charles McCathieNevile <charles@w3.org> on 02/15/2000 01:41:33 AM
  
  To:   Richard Schwerdtfeger/Austin/IBM@IBMUS
  cc:   User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>, WAI PF group
        <w3c-wai-pf@w3.org>
  Subject:  DOM events Re: PROPOSAL: User Agent Issue 190:
  
  
  
  
  Cross posted to Protocols & Formats and User Agent groups
  
  I think we should take a step back and look carefully at this again.
  
  Implementing an event model is important if we accept that the web that is
  moving into the future is going to rely on scripting and dynamic
  effects. Although there will be a requirement for some time to come that it
  be possible to use the web without these things, I believe that by ignoring
  them altogether we are hiding our heads in the sand - we must work out how
  to make them accessible.
  
  The basic requirement is to make the interactions that the user can have,
  as
  defined by the content itself, available to the user without requirement
  for
  a specific type of hardware interface. For example, relying on the presence
  of a mouse, or of a visual display of a certain size, is unreasonable.
  
  In HTML terms, what is required is that the User Agent provide some
  mechanism
  to programmatically trigger the event trigger attributes, and that that
  function is also available in a device-independent manner to the greatest
  extent possible.
  
  One approach to this is to look at the new DOM event set, and map the
  current
  HTML towards that set. (For a note on why this is a good idea, read the
  original HTML 4.0 specification at the relevant point...)
  
  Here is a possible way to handle the events:
  
  onClick, onDblClick, onKeyPress, onKeyDown, onKeyUp can all be mapped to
  the
  new onActivate, using a parameter where appropriate. I would suggest that
  the
  value of the parameter be numeric, and that we require of the DOM group
  that
  this event be able to take sufficient parameters to encompass a multiple
  click, or differentiating between some number of different keys (I would
  suggest that 10 is a better number than 2, for example)
  
  onMouseOver, onFocus be merged to the new equivalent, and similarly with
  onMouseOut and OnBlur.
  
  onMouseMove is a bit tricky. Where mouse things are used with X,Y
  parameters
  there is some careful thinking needed to work in a non-visual space - in
  some
  cases a more object-oriented approach will solve the problem (this is a Web
  Content Question), but there are cases where it is just very difficult -
  the
  same problem that arises in trying to deal with raster-based graphics.
  
  I think the rest of the events can stay as they are. Gregory has already
  pointed to the potential problems raised by ill-considered use of mutation
  events such as onChange for submitting forms, and in any event that does
  not
  rely on a particular type of user interface.
  
  To a certain extent this is going over old ground. Which I find extremely
  frustrating, but think is pretty important and we still need to get it
  right.
  
  Charles McCN
  
  On Mon, 14 Feb 2000 schwer@us.ibm.com wrote:
  
  
  
  
    This is why we were pushing the DOM2 event model as P2.
  
    It is unrealistic to expect the DOM WG to scrap their entire event model
    for accessibility. We should be able to improve upon it in terms of
  device
    independence. Having people start developing to the DOM 2 event model
  will
    not require them to rewrite the whole thing.
  
    I do appreciate your concerns.
  
    Rich
  
  
  
  

--
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 Tuesday, 15 February 2000 12:34:06 UTC