RE: Seeking guidance...

Right. In newer markup languages, the focus event will provide a function
that can be accessed by keyboard, or mouse, or by asking for the next element
in an audio environment, or respond to an event being eyeballed (actually
retinal scanning can tell what you are looking at). Currently we have to
duplicate code in HTML. (As noted before, the model in SVG is a lot better).

I don't think the current onFocus gets us nothing, just not enough. As you
say, it should also cover mouseovers, and should apply to any element.

I have started to write some notes on all this stuff since I have been going
round almost the same path (although I have learned a bit in that time) for a
couple of years.

My very rough notes are at http://www.w3.org/2000/04/event-di - any feedback
is welcome although I can't promse to have a lot of time to spend on this.

cheers

Charles McCN

On Fri, 7 Apr 2000, Bruce Bailey wrote:

  This is what I am talking about!  onMouseOver IS (to my way of thinking) a
  pointer-oriented version of onFocus.  The way onFocus has been interpreted
  (again, from a pointer-oriented perspective) is as an onClick.  This is
  WRONG.  The device-neutral equivalent for this might be "onSelect" -- quite
  a different animal!
  
  No, you can't tell where the user's eye is actually reading.  onMouseOver is
  a fair attempt at making a guess and the result is usually non-obtrusive and
  requires minimal effort on the part of the user.  BUT it is only good for
  folks who are by both ability and inclination pointer oriented.  There
  SHOULD be some workable keyboard-oriented equivalent, but based on this
  discussion, I must conclude that there is not!  Even better, would be
  device-neutral equivalent, but apparently the rather easy case of a
  visually-oriented-but-keyboard-avoiding surfer (there of plenty of them)
  isn't even adequately addressed!
  
  onFocus SHOULD support any keyboard-oriented user (sighted or not) -- but it
  also should be a REPLACEMENT for pointer-oriented attributes that are in
  common use now.  onMouseOver is EXTREMELY popular (much more so than
  onClick).  Better yet, there would be a device-neutral attribute that
  supported BOTH mouse and keyboard (since onFocus ain't it).  IMHO the
  current definition of onFocus is BROKEN and gets us NOTHING.  No harm with
  including it, but why advocate for it and not a mythical element like
  onProximity or whenFocusIsNearby ???
  
  Having ranted, let me attempt amends by attempting a summary:
  As a matter of actual practice, one could (and should) duplicate onMouseOver
  attribute content with onFocus (TABINDEX might have to be added too).
  Anyone who complains about their code becoming invalid should be excused
  from this requirement.
  
  Len -- how about adding this to the WAVE?
  
  For what it's worth, AbleTV.net (which got me started in this thread)
  doesn't have to worry about onFocus making their code invalid!  SMILE.  I
  hate recommending code duplication, but I don't see a way around it.
  

--
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 Friday, 7 April 2000 15:16:17 UTC