onmouseover, onfocus, onclick

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One of the problems with menus like we have discussed is that we can
take the following as being an order of how interested a particular
event means a particular user is in a particular event (can I use the
word "particular" any more in this sentence?):

onfocus - not very interested, quite possibly just tabbing through.
onmouseover - pretty interested, if user is just passing the element
will onmouseout soon
onclick - very interested

onclick is normally triggered by pressing enter when an element has
the focus, in could perhaps be more accurately named "onactivate".

Designers often want to use onmouseover rather than onclick to
trigger menus like this because firstly it is visually more
impressive (it makes the page seem that bit more responsive), and
also there is the question of when a menu that is activated by
onclick should disappear again (not that easy a question to resolve).

The keyboard-triggerable event closes to onmouseover is onfocus, but
as I said above it doesn't indicate as much interest in an item as
onmouseover. There is also the problem of tab order, unless the menus
sub items are next in tab order they may not be selected at all, as
by the time they are tabbed to the onblur event has triggered for the
controlling menu item, and the submenu has disappeared (hence taking
it's elements out of the tab order).

There is another issue with onmouseover from an accessibility
perspective; it can be difficult for people who have enough motor
control to use a mouse, but who do so slowly or jerkily to select the
sub items. I've come across plenty of menus like this which are hard
for me to use without the onmouseout triggering while I try to use
it, and I'm a regular Quake player!

I would have two recommendations on this:

Ideally I would trigger menu appearance or disappearance from
onclick. Since onclick events occur when a focused item is selected
from the menu, this would be workable for keyboard users if the sub
items are the next elements in the tab order. An onclick event
anywhere else on the page should hide the menu, and possibly an
onfocus as well (depending on layout this may clarify or confuse
matters).

Second best would be to use the mouseover, but also react to onclick
(or perhaps only onkeypress if it is the return key that has been
pressed) by displaying the submenu until onclick occurs again, or
focus or click happens elsewhere (indicating the menu is no longer of
interest). The main problem with this is having two different ways of
triggering and cancelling the menu can complicate the script
considerably.

Last best would be to use the mouseover, but have an onclick go to a
page which has that menu's items in a simpler format. Perhaps this
would be worth doing if onclick happens without onmouseover happening
first - indicating the menu was selected by keyboard, although with a
slow processor this could happen anyway if the user clicks quickly.

These wouldn't work if clicking the menu naviagated to another page
as well as mousing over it making the submenu visible, as with the
popular scripts from http://www.webreference.com/dhtml/ but I
consider this poor UI design, and confusing for people used to the
drop down menus of most GUI operating systems (familiarity with which
is presumably one of the points of these menus anyway).

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>

iQA/AwUBOoriMdlYbmO7kSNQEQLcCQCgiu9xZe8CuQuaeuarXITMZcUTSyoAn0XI
ah9EtpVSvRdLroxvAHTceJv5
=sC1H
-----END PGP SIGNATURE-----

Received on Wednesday, 14 February 2001 14:52:59 UTC