Cross-browser, Pure CSS Drop Down Menu
Here is an awesome pure CSS, cross-browser drop down menu that can easily be plugged into any site.
The original script is a bit bulky at 10 KB (a whopping 296 lines of code!) but I was able to bring it down to 4.1 KB with a little help from CSS Optimiser.
You can download the optimized version here.
January 10th, 2008 at 12:46 am
Yet like every other CSS-based menu I’ve seen, this one is hard to use and rather inaccessible:
* Navigation options are hidden from the user, forcing the user to search around.
* It’s impossible to open the menu with an iPhone (touch screens don’t have hover events).
* You can’t easily open the menu by tabbing around with the keyboard or a switch access device.
* Most screen reader/browser combinations operate with CSS applied. The menu contents are hidden with “display: none;” for all media, even though display hides content in aural media as well as visual media by spec (http://www.w3.org/TR/CSS21/aural.html#propdef-speak) and even though (notoriously) many screen reader/browser combinations will not read content with “display: none;” applied even if it’s expressly applied only to screen media (http://css-discuss.incutio.com/?page=ScreenreaderVisibility and see also: http://www.w3.org/TR/WCAG20-CSS-TECHS/C7.html).
* If you disable author-suggested CSS, the number of links is arguably excessive (compare discussion at http://www.456bereastreet.com/archive/200705/accessible_expanding_and_collapsing_menu/).
I’d suggest (a) creating a site flow that doesn’t require hiding large numbers of options from the user or (b) where this is impossible, or where a desktop application-style menu is being faked as part of web application, use a JS-based menu that works on anchor click events that are triggered with keyboard, touchscreen, or mouse, such as UDM4 (http://www.udm4.com/) or YUI menu (http://developer.yahoo.com/yui/menu/).
February 18th, 2008 at 10:56 am
this is a brilliant piece of work, you are to be strongly commended.
“Yet like every other CSS-based menu I’ve seen, this one is hard to use and rather inaccessible:”
whine all you like, but to create a menu that works purely in css and functions cross browsers is awesome. Like all things web developers do, you are limited by cross browser compatibility, and its not always good to rely on javascript.
* Navigation options are hidden from the user, forcing the user to search around.
Isn’t this the case with all drop down menus?
* It’s impossible to open the menu with an iPhone (touch screens don’t have hover events).
Isn’t this the phones fault.. I mean really.
* You can’t easily open the menu by tabbing around with the keyboard or a switch access device.
Yes, this is a pity… but I think you make some accessibility sacrifices when you use a drop down menu full stop.
May 18th, 2008 at 4:24 am
wouldn’t it be possible to add tabindexes to all links in the menus and set them visible on focus?
June 2nd, 2008 at 6:12 am
leighli writes:
“whine all you like, but to create a menu that works purely in css and functions cross browsers is awesome.”
Is it? What is the value to the end-user in restricting the number of technologies used if that restriction results in a menu that doesn’t actually function properly? Even if it were a neat trick technically speaking, it’s being promoted here as something that’s suitable for production use and that’s accessible; it’s plainly neither. You could add text content to paragraphs with CSS content generation (”pure CSS text!”), but that wouldn’t be more accessible than putting the text content in the correct layer (HTML). Likewise, you could produce layouts without CSS (”table layouts for the single-technology win”), but that wouldn’t be more accessible than putting presentation in the correct layer (CSS). JS is the correct layer for behavior. (In the future, it’s possible that CSS will adapt to support more suggestions for behavior and, once implemented in common user agents, it might be possible to create device-independent scriptless dropdown menus. But that day is not today.)
“Isn’t this the case with all drop down menus?”
Absolutely, hence my suggestion (a).
“Isn’t this the phones fault.. I mean really.”
Not really. First, if web publishers followed best practices the hover effects would be an enhancement not a prerequisite for using such menus (http://www.w3.org/TR/WCAG10/#gl-device-independence). Second, hover effects in webpages are not easy to reconcile with touch screens, especially multitouch touch screens.
“Yes, this is a pity… but I think you make some accessibility sacrifices when you use a drop down menu full stop.”
Sure, but that’s hardly a reason to make completely unnecessary /additional/ accessibility sacrifices in pursuit of an ideal (”pure CSS”) that has no end-user value.
andy asks:
“wouldn’t it be possible to add tabindexes to all links in the menus and set them visible on focus?”
Well, first, be wary of TABINDEX’s many shortcomings (http://www.rnib.org.uk/wacblog/general-accessibility/too-much-accessibility-tabindex/). Second, TABINDEX isn’t necessary for the anchors in the menu to receive keyboard focus because they have HREF. Third, items with display: none; set won’t normally receive keyboard focus, even with TABINDEX. Fourth, setting :focus styles on the sublist anchors won’t help since it is their UL ancestors that are set to display: none; and you can’t select a ancestor via its descendants in CSS.
September 21st, 2008 at 6:19 am
Excelent! Thank for link, it is exactly what I was searching for.