1. Older people have difficulties with drop-down and multi-level menus, because their manual dexterity, eye-hand coordination and space perception decreases. Also some move the mouse when clicking, or tremble, hence it’s more likely they slip off the menu. Hell, that happens to me frequently!

   However, did you notice the Windows Start Menu is more forgiving when you slip off an item? There’s a little delay before the secondary level is hidden. Perhaps we need an event-capturing script tolerating a slip from the menu rather than the immediate reaction of the mouseout event.

2. Nested menus are more complex. According to Hick’s Law orientation in a multi-level menu can take longer than multiple clicks in a flat menu with good information architecture. See an earlier article for the math.

3. The navigation must be accessible by keyboard alone. The result should be the same, whether you hover over an item or tab to it. So check for the focus event and CSS pseudo-class. Don’t forget to test backwards tabbing (shift tab). By the way, mobile devices have no mouse either…

   The tab order should be consistent and logical, i.e. not jumping around on a page. Also the focused item should be visible, for example highlighted with the default 1px dotted border some browsers draw around it. Some people think this is ugly and remove the default border. That is a no-no.

   And if you really want desktop behavior, add support for the arrow keys (event.keyCode 37-40). Keep in mind though that screen readers have predefined functions for the arrow keys in combination with the ctrl, shift, or alt keys. In JavaScript those keys can be detected with the event.ctrlKey, event.altKey, and event.shiftKey properties. Also crossbrowser event delegation for focus or blur events can be a bitch, thankfully PPK has a solution.

4. Users of AT should have means to skip content. That’s possible with semantic markup: a menu as (nested) list(s) enables them to jump to the next block. Also there should be a few skip links at the beginning of the code pointing to important sections on the page, such as content, navigation, or search. Mobile users also profit from that technique (try surfing eBay with Opera Mini ).

5. Pages never link to themselves. When I click on a link (the menu being no exception) I expect to land on a different page. Therefore it’s confusing to land on the same page. This happened to me recently when I was filling out a form on my mobile phone and got the same page with an error message. It took me a while to realize where I was. It’s the same whether you have a tiny screen or a low screen resolution to see things larger when you are visually impaired: you only see a small part of the page, so it’s hard to realize when something unexpected happens.

6. You can add some semantic sugar with the ARIA role property. In this case <ul role="navigation"> would be appropriate. I strongly encourage you to use ARIA as it is widely supported by browsers and screen readers, enhances a disabled user’s experience, and doesn’t break old browsers. A most recent introduction has been written by Gez Lemon for the Opera Developer Community.

7. If a second level navigation is initially hidden with display:none it won’t be in the screen reader buffer. Therefore off-screen positioning is a better idea, else you need to update the buffer by writing random values into a hidden input field.

8. A common problem in menus is limited horizontal space. Text should be scalable, and it must not jut-out into other page elements when it is enlarged. Even normal text can break a narrow menu when you think of internationalization. In German there are many composite words. While building a website for a competing brand I came across a menu item on the Philips website for “male grooming.” The German word „Körperhaarpflegesystem” is guaranteed to blow every menu!

   Another common problem that prevents scaling in menus are text graphics. I know marketing just loves to see the corporate font in the main menu, but text in images can’t be scaled, people with visual impairments can’t change text and background colors for higher contrast, and Flash Image Replacement like sIFR still has accessibility issues, is known to distort fonts, is CPU intensive and slow. The bottom line is: don’t use text as images, make textual information text.

So much for accessibility. Besides there are a few technical issues to consider: mobile devices often have problems with JavaScript or with layers. Some proxies in large companies filter JavaScript for security reasons, so you can’t rely on the ubiquitous availability, your script has to be unobtrusive, and you can’t rely on noscript either. Don’t even think of creating a menu from JavaScript arrays.

Moreover there’s a well-known bug in IE6 responsible for showing select lists always in front of any layers (like your second level menu), regardless of a z-index. Thankfully there are plugins like bgiframe for jQuery to solve this. Multi-level menus can bloat the code, event handling can be CPU intensive (use event delegation). And if large amounts of menu code is at the beginning, the real content gets further behind and less relevant for search engines.

In conclusion, for an alleged quicker entry you pay with many disadvantages. Often drop-down menus just conceal a poorly planned information architecture. I would reconsider their usage.

Did I forget something? What’s your opinion on drop-down menus? Love them or hate them?

1. The geek meeting in Frankfurt known as Webmontag will be held for the seventh time at the Brotfabrik. So far there are short lectures about a social photosharing network, semantic webworking P2P transactions, and a wireless match maker, but you are free to present your own work and research.

   After all, this is an informal meeting organized through a Wiki where you can participate and share your knowledge. Not necessarily technical knowledge, also designers, project managers, and information architects have been spotted — I wish they would speak up more often. Admission is free, so if you are in the Frankfurt area you have no excuse not to attend.

2. The second conference almost slipped my radar: it’s the First European e-Accessibility Forum in Paris, organized by the French accessibility entity BrailleNet and EDeAN (European Design for All e-Accessibility Network). While I can’t say much about BrailleNet, EDeAN is the official accessibility outreach organization of the EU. So far they have kept a low profile doing politics and research in the background, but it’s about time more people learn about their existence.

   For only € 90 you get a day packed with high quality accessibility information from industry leaders: Microsoft’s French Technical Director speaks about accessibility in the Web 2.0 context. IBMs Rich Schwerdtfeger, member of both the WAI Protocols and Formats Working Group and the HTML Working Group, is next with accessible rich internet applications (ARIA). Among other speakers, there will be Christian Heilmann (Yahoo!), Michael Cooper (W3C / WAI), Steven Faulkner (developer of the Web Accessibility Toolbar), Dave Wilton (Legal & General, the insurance company that got best practice credits in the UK’s PAS 78), Julie Howell (former accessibility champion of the Royal National Institute of the Blind), Dominique Hazaël-Massieux (W3C), and Miguel González-Sancho (European Commission). They will talk about accessibility and the Mobile Web, the UbiWeb, harmonization of European accessibility and a European label, or present a couple of case studies from print, banking, and job websites.

   You better be fast for that one, registration is only open until Saturday, January 20th.

3. Last but not least the website for the @media conference has been updated yesterday, so you can register for the event in London, June 7th and 8th, or earlier in Asia and the US. Last year’s event was fun and inspirational, so start fast-talking your employer now!