W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2000

Re: making onmouseover accessible

From: Charles McCathieNevile <charles@w3.org>
Date: Mon, 5 Jun 2000 18:11:44 -0400 (EDT)
To: "Leonard R. Kasday" <kasday@acm.org>, Marja-Riitta Koivunen <marja@w3.org>
cc: WAI IG <w3c-wai-ig@w3.org>
Message-ID: <Pine.LNX.4.20.0006051800480.25127-100000@tux.w3.org>
I am not sure I agree with this position. THer are users who just use a
mouse. There are users who just use a keyboard (or would like to, if software
allowed it). And there are users who do both. While we are at it, we might as
well also consider users who have a stylus or touch screen.

Len is right that in the current model, focus refers to keyboard focus, and
mouseover referes to mouse focus. My understanding of how this works in the
real world is that users have a focus, and a method (or two) of shifting that
focus from item to item. Unfortunately, programmers have taken the seperate
methods of assigning focus and made them work in different and not
necessarily compatible ways. This, to my mind, is an error, because it fails
to account for people who cannot use one or the other method.

Looking out to the graphical desktop interface that a lot of this stuff came
from, we find a slightly different user interface, which leads to the same
kinds of functionalities (and some much more powerful ones besides). At the
same time, it does not make the artificial seperation between mouse users and
keyboard users.

Simply put, they did a better job. Not perfect (there are still things that
only seem to work in one modality for most such systems), but better.

So what we need is a new model - one which does not rely on the user having a
particular set of input devices and feedback capabilities - and then
languages which incorporate this model, and then software which implements
it. And we do need it - at the moment we are working in systems that disable
some users by poor design, rather than externally imposed constraints.

Charles McCN

On Mon, 5 Jun 2000, Leonard R. Kasday wrote:

  As Charles indicates, this discussion keeps reappearing.  I just want to 
  try again to make a point which I guess I didn't get across in earlier 
  discussions.  The point is this:
  
  "focus" cannot logically be made the same as "mouseover"
  
  That's because "focus" is keyboard focus:  the object with keyboard focus 
  is the object that will get keyboard events.
  wherease
  "mouseover"  is MOUSE BUTTON focus: the object with mouse button focus is 
  the object that will get mouse click events.
  
  For example, if my text cursor is in a text field, that text field has 
  keyboard focus, but I can move the mouse over a link.  e.g. for purposes of 
  clicking on that link.  When I move the mouse over that link, I'm giving 
  the link mouse focus without disturbing the keyboard focus.
  
  Thus, any solution which to make focus and mouseover the same will deny 
  full functionality to people who are not using a mouse (or mouse 
  equivalent).  This is because if the user has just one focus, s/he will 
  lose his/er keyboard focus when moving the single focus to where mouse 
  focus is needed.  And visa versa.
  
  Whats really needed is separate keyboard control of mouse focus, either in 
  the user agent, or in the assistive technology attached to the user agent.
  
  Len
  
  At 05:36 PM 6/5/00 -0400, Charles McCathieNevile wrote:
  >The story (as far as I understand it, and I have been following it for a
  >couple of years now) goes like this:
  >
  >javascript effects do not reliably work in all browsers. So it is important
  >not to rely on Javascript for function. There are two parts to this. One is
  >to do as Len suggested, and provide a server-side equivalent (for example
  >form validation can be done on both sides). The other (especially where there
  >is no real functionality added to the page, for example in a mouseover
  >highlight, is to add a focus event - most good browsers will allow the user
  >to focus an element via the keyboard, and functionally a mouseover is
  >equivalent as a user behaviour, although for historical reasons the language
  >support for this is fairly poor (HTML provides fair to appalling support for
  >this aspect of accessibility and browser implementations tend to fall a
  >little short of that. Sigh. I am pleased to note that there are great
  >improvements in the model being used by the Scalable Vector Graphics
  >language, although I am waiting to see the implementations at work).
  >
  >Charles McCN
  >
  >On Mon, 5 Jun 2000, Leonard R. Kasday wrote:
  >
  >   There was a thread back around the beginning of april about text menus 
  > that
  >   popped up when the mouse passed over them (the celebrated "mouseover"
  >   action), and how to make them accessible.  The discussion seemed to end at
  >     http://lists.w3.org/Archives/Public/w3c-wai-ig/2000AprJun/0015.html
  >   without an answer.
  >
  >   There's a simple way to make a functional equivalent of mouseover on a
  >   object if there isn't something already defined for clicking on that
  >   object.  Just make that object a link so when you click on it it brings up
  >   a new page with content equivalent to what pops up with the mouseover.
  >
  >   What if the button already does something, say it's a link and the
  >   mouseover brings up summary info that helps you decide if you want to 
  > click
  >   that link?  In that case you could have an additional link you'd click to
  >   bring up the info.  Similar to a D link.  Perhaps an "M" link?   You could
  >   make the "M" links visible or not under control of a style sheet.  Also,
  >   the page brought up by the M link would have a link to what clicking on 
  > the
  >   original object would have produced.
  >
  >   Instead of an M link you could have a transparent image to which you could
  >   add appropriate alt text. Hmm... - except a transparent image wouldn't be
  >   suitable for sighted people with motor disabilities.
  >
  >   Of course, you also have to be sure the average user knows about this 
  > stuff.
  >
  >   There's also the long description but that may be used for other stuff and
  >   isn't yet implemented on all browsers.
  >
  >   Len
  >   --
  >   Leonard R. Kasday, Ph.D.
  >   Institute on Disabilities/UAP, and
  >   Department of Electrical Engineering
  >   Temple University 423 Ritter Annex, Philadelphia, PA 19122
  >
  >   kasday@acm.org
  >   http://astro.temple.edu/~kasday
  >
  >   (215) 204-2247 (voice)  (800) 750-7428 (TTY)
  >
  >   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
  >Postal: GPO Box 2476V, Melbourne 3001,  Australia
  
  --
  Leonard R. Kasday, Ph.D.
  Institute on Disabilities/UAP, and
  Department of Electrical Engineering
  Temple University 423 Ritter Annex, Philadelphia, PA 19122
  
  kasday@acm.org
  http://astro.temple.edu/~kasday
  
  (215) 204-2247 (voice)  (800) 750-7428 (TTY)
  
  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
Postal: GPO Box 2476V, Melbourne 3001,  Australia 
Received on Monday, 5 June 2000 18:11:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:13:49 GMT