Re: Technique 9.3.1 Check scripts for logical event handlers

Actually,  I would make this a focus element on the boxes, which may or may
not be triggered as a mouseover. For keyboard efficiency you should use a
keyboard-relevant solution, for example a "jump 10 steps/onepage/some other
amount/some structure piece". Since I can't think of another keyboard
interface that makes the thing accessible, and generalises.

To make this editable, being able to remap the focus from mouseover / moving
the cursor to rightclick/active focus key/ etc, is much better than simply
having to drop the function from any would-be WYSIWYG editor (witness the
problems dealing with Javascript in Mozilla's editor...)

I believe that this provides a device-independent way of working, by moving
away from mouseover as a mistaken confusion of the action (mouseover) with
the behaviour (focus).

In a better language we would simply replace the mouseover, but we don't have
a better language yet.

Charles


On Thu, 21 Sep 2000, Leonard R. Kasday wrote:

  Here's another example of why we need to make mouseover independent of focus.
  
  Imagine a  stock trading page.
  
  Lots of stock boxes.  Each box contains  3-letter abbreviation of 
  stock,  and two text fields follow each: one for buy, one for sell.
  
  When field gets focus, full name of comany appears, as safety factor in 
  case you remembered abbreviation wrong.
  
  Another feature: when you mouseover anywhere in any stock box, either on 
  the abbreviation or the text fields, a graph of past weeks prices, and/or 
  other information pops up..  So trader can wipe mouse over page, quickly 
  looking at graphs that pop up, looking for good deal.
  
  If we try to make mouseover same as focus we run into problems.
  
  First of all, as described here, different things happen depending on 
  whether text box gets mouseover or focus.  So you simply can't make 
  mouseover and text focus the same without modifying the interface.
  
  Now, you could modify the interface, so that you only get the popup graph 
  when you mouseover the abbreviation, not when you mouseover the text 
  box.  Then you just have to make mouseover equal focus for the 
  abbreviations.  However, besides making it a bit less convenient for person 
  with no disabilities, it makes it worse for a person with a motor 
  disability that makes mouse pointing less precise.
  
  Also, this forces you to make abbreviations accept focus, which means that 
  as you tab though the field
     these graphs keep popping up, annoying people without disabilities, 
  distracting people with some cognitive disabilities, doubling the number of 
  keystrokes for people with motor disabilities,  and creating speech clutter 
  for people who are blind.  Plus putting a extra load on the server.
  
  So it would be better to give use independent control of the so-called 
  mouseover.
  
  As I indicated, I don't know of any page that works like this... I just 
  made it up.  But I think it shows a plausible case where independent focus 
  and mouseover is needed, and there will likely be others, given the 
  zillions of people creating new pages every day.
  
  What what do you'all think?  Shall we ship this as an open issue to WCAG?
  
  Len
  
  Hmmm. I wonder if anyone will actually want to build this interface... 
  well, just in case...
  
  I hearby declare this stock trading interface Copyright (c) 2000... if you 
  want to use it commercially give me a call to discuss royalties  .. this 
  does not apply to accessibility accommodations of course.
  
  
  At 08:00 AM 9/21/00 -0400, Charles McCathieNevile wrote:
  >If we don't require it then we are deviating from WCAG, which is a bad step
  >on the loss of interoperability of W3C specs path. (In particular, it would
  >mean that the AU group, which relies on WCAG by reference, would have to work
  >outside the AERT). If indeed this is unnecessary then the first requirement
  >should be to suggest so to WCAG.
  >
  >So much for process.
  >
  >Where there is a stylistic change caused by a mouseover, it is done as a way
  >of providing an effect when the user is focussed on the event. There is no
  >good reason why this should be restricted to mouse users. In particular, this
  >is often used to draw attention to something - that has value for a number of
  >different types of users. As content becomes better written, we can expect
  >more such effects, and more of them to use generally accessible features like
  >CSS changes (this is how it  is done using SMIL/SVG animation).
  >
  >If there are examples where a mouseover and a focus event do different
  >things, then I have yet to discover it. They may have different meanings in
  >specification, but the first is a subset of the latter in most user interface
  >design for the web. (For Operating systems, by contrast, single-click takes
  >the place of mouseover for certain types of objects, but not others).
  >
  >Charles McCN
  >
  >On Wed, 20 Sep 2000, Leonard R. Kasday wrote:
  >
  >   I think, and I'd guess this agrees with what Chris had in mind, that 
  > no, we
  >   don't need a mouseover replacement there.
  >
  >   This brings up another problem though.
  >
  >   What if an object already has both a mouseover and an onfocus event?  They
  >   are logically different after all.
  >
  >   Simply replacing the onmouseover with onfocus doesn't work in that case.
  >
  >   Len
  >
  >   At 03:31 PM 9/20/00 -0400, Chris Ridpath wrote:
  >   >Do ALL device specific event handlers (e.g. OnMouseOver) require 
  > replacement
  >   >with device independent handlers (e.g. OnFocus)?
  >   >
  >   >Many pages use OnMouseOver to change the appearance of buttons on the 
  > page.
  >   >This is a small change in appearance and does not affect the functionality
  >   >of the page if it's missing. Should we require that these pages add an
  >   >OnFocus handler as well as the OnMouseOver?
  >   >
  >   >Chris
  >
  >   --
  >   Leonard R. Kasday, Ph.D.
  >   Institute on Disabilities/UAP and Dept. of Electrical Engineering at 
  > Temple
  >   University
  >   (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
  >   http://astro.temple.edu/~kasday         mailto:kasday@acm.org
  >
  >   Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
  >   http://www.w3.org/WAI/ER/IG/
  >
  >   The WAVE web page accessibility evaluation assistant:
  >   http://www.temple.edu/inst_disabilities/piat/wave/
  >
  >
  >--
  >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, Australia
  >September - November 2000:
  >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, 
  >France
  
  --
  Leonard R. Kasday, Ph.D.
  Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
  University
  (215) 204-2247 (voice)                 (800) 750-7428 (TTY)
  http://astro.temple.edu/~kasday         mailto:kasday@acm.org
  
  Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
  http://www.w3.org/WAI/ER/IG/
  
  The WAVE web page accessibility evaluation assistant: 
  http://www.temple.edu/inst_disabilities/piat/wave/
  

-- 
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, Australia
September - November 2000: 
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France

Received on Thursday, 21 September 2000 11:37:01 UTC