[thelist] CSS drop down menus

VOLKAN ÖZÇELİK volkan.ozcelik at gmail.com
Mon Jul 11 03:10:14 CDT 2005


http://www.sarmal.com/lib/web/sarmal/script/sardalya/DropDownMenu_Test.html

inspired from Chris's YADM and sun of suckerfish and several other menus around.

It enables hover, click, and tab navigation. accesskeys can be given
to menu elements as well but have not tried yet.

It formats an unordered list into a dropdown. It includes a
configurable timeout, so the menu does not goes away, a good thing for
people with motor-skill exceptions.

It relies on javascript 
(
any accessible/usable menu has to rely somewhat on javascript to
enhance functionality imho. Don't get me wrong. I don't mean fancy
rollover/transition effects when I say "javascript". JS should be used
to enhance
functionality.

 I will say "just no, hell no!" to vendor-specific fancy transition effects.
)

I've not addressed "the very-long hierarchical menu bleeds off the
screen " issue but I'm thinking on a solution to it.

It degrades to an unordered list when javascript is off. However it
does not degrade very gracefully (it still preserves CSS  button-like
look and feel, though it is not hard to sort it out.)

It's still under design phase. It needs several
usability/accessibility tweaks. I plan to make a code/css review as
soon as I have time.

Coming to Chris's comments:
 
> Suckerfish is a very elegant technical solution, however, before using
> dropdowns there are some things to consider in terms of accessibility
> / usability:
> 
> 1) Most CSS only dropdown navigations are not keyboard accessible -
> some are but only on non-mainstream browsers

I totally agree with you and respect your evangelism on the issue.
We are discussing them over and over again. But imho, the world is
evolving to a more accessibility-aware state.

> 2) A lot of dropdowns are too fast in hiding the elements, which means
> that a visitor with bad hand-eye coordination will get really
> frustrated when you hide and show on hover rather than onclick.

I think (and afaik w3c recommends) if hover is used, "onclick", "onfocus"
or both should be provided as well. You cannot rely on mouse-only solutions
(even keyboard only solutions (onclick) are debatable. The solution should be
independent from the input devices as much as possible.)

> 3) When you use dropdown navigations you assume the visitor has enough
> screen estate to show them all, she might not and lose the navigation
> when scrolling the viewport

That's another reason why I don't use dropdowns unless the client
explicitly requests it.

> 4) With multi level dropdowns there is no "you are here" state, the
> visitor will need to go through all levels on every page

This is another handicap. CSS is "stateless" (this is also discussible
on what you define as "state")

> 5) Without CSS and/or without JavaScript, the visitor will get a lot
> of links not related to the current section. This might confuse and
> can be annoying if you are only using a keyboard, as you have to tab
> through the lot of them.

imho even the most accessible dropdown navigation should be provided
with additional helpers such as "skip navigation" link, tab indexes
which makes the user tab to an alternative side/bottom navigation.
before tabbing through all the elements, sub-elements and
sub-sub-elements etc. etc.. of the dropdown menu.

> 
> Just something to think about.
> 

Something to deeply think about.

Cheers,
Volkan.


More information about the thelist mailing list