E-mail List Archives
Re: drop down menus
From: Al Sparber
Date: May 29, 2009 9:20AM
- Next message: Al Sparber: "Re: drop down menus"
- Previous message: ben morrison: "Re: drop down menus"
- Next message in Thread: Al Sparber: "Re: drop down menus"
- Previous message in Thread: ben morrison: "Re: drop down menus"
- View all messages in this Thread
From: "Peter Weil" < <EMAIL REMOVED> >
> On May 29, 2009, at 2:38 AM, Al Sparber wrote:
>> So-called "pure" CSS menus are sometimes accessible, but never
> I know that this can be a provocative topic (previous threads on this
> subject never seemed to arrive at satisfactory conclusion), but we are
> also looking into the possibility of incorporating dropdown menus.
> However, accessibility/usability is an absolute requirement -- it's
> one of the reasons that we have avoided them in the past. Would you
> a necessary component?
without the ability to perfectly aim a pointing device to "miss" a bit
without snapping a menu shut or causing the wrong menu to be revealed.
Imagine a menu section, 6 links long. Its first menu item triggers a
sub-menu to fly out to its right. The sub-menu has 10 items. The link you
want to execute is the 8th one down. In order to access this with a mouse or
pointing device, you must move straight across the trigger item until you
reach the fly out menu, then go straight down. The natural inclination is to
move at a diagonal from the trigger to the target link. When you do this,
you brush over the link below the trigger and the fly out menu snaps shut.
The "L-shaped" path one must take in this scenario is not natural and only
seems to be tolerated by web designers that are also proponents of pure CSS
menus and thus understand how they work. In the wild, these menus cause
severe frustration. We have done extensive usability testing that bears this
It doesn't get any better. Scripted menus that are done well have many other
features that assist in usability. These include:
Edge detection that helps to ensure that if a menu's natural position would
have it go beyond the visible edge of the window, it is re-positioned
Link highlighting to mark a link in the menu that corresponds to the current
Keyboard access - though I think the best multi-level menus eschew all
keyboard support and instead are deployed in the manner discussed in my
CSS (at this time) is a presentational component, not a behavioral one. It
is likely that in the future, CSS and markup will be used in concert with a
browser's internal script engine to create behavior, such as menus that
operate precisely according to OS UI convention. That day is years in the
Hope this helps a bit.
Al Sparber - PVII