The Footer’s the Menu
Drop-down and fly-out menus often come with a whole range of usability and accessibility problems — skittish behavior, content that disappears below the fold, or lack of keyboard access, to name but a few. For the most part, though, these problems are solvable (see: “The Right Way to Make a Drop-down Menu” for more).
However, there’s another issue that’s trickier to address: the question of how and where to create the content these menus use.
There are basically two options:
- Create the menus as hierarchical lists in hard-coded HTML. The top navigation bar is an unordered list, and each of its submenus is a nested list, a child of the top-level item that triggered it. The problem with this approach is that it means creating a large structure in HTML, which can be quite annoying for screen readers and other serial devices to navigate their way through. Put simply, it’s a whole lot of content to put in static HTML, when some user agents lack the ability to selectively show and hide it.
Neither of these solutions are perfect; one group suffers reduced usability, or another user group suffers reduced accessibility. If only there were a third way …
The Third Way
The image below is an abridged screenshot from a sample web page that’s typical of many site designs, in that it has both a header and a footer:
The header and footer of a sample web page
The header contains the primary navigation from which the drop-down menu would be triggered, and the footer contains supplementary navigation. Notice anything similar about them?
Each link in the top navigation bar is to one of the main sections of the site. And each set of links in the footer is for the same main sections of the site. They correspond exactly, and when it comes to implementing the drop-down menu, it’s likely that it will contain the same links we see in the footer.
In other words, the footer is the menu. So why not literally make it the menu?
Send in the Clones
Let’s design a menu with a single list of links as the top navigation bar; then, when a mouse or keyboard event triggers the appearance of a drop-down menu, we’ll create that menu by cloning the corresponding section of footer links.
This is the best of both worlds:
- We do have the menu content in static HTML, but it’s structured, usable, and out of the way. The usability issue with having all the content there by default is solved.
- We are generating the menus on the fly, but we’re doing it using content that nevertheless exists in static HTML. The accessibility issue with using dynamically created menus is solved.
I’ve made a fully functional demo to illustrate this concept, adapting a menu script from the drop-down menu post I linked to earlier. The menu script is imperfect; if I had more time I’d tighten up the event flow (and test it in IE6!) — but it should serve to demonstrate the concept nicely, and it’s a good starting point if you wish to develop this idea further.
Making Mega Menus
And we can take this concept a whole lot further! Recently I did some work for Amnesty International Australia, where the site design called for complex mega menus containing large amounts of content:
A mega menu from the Amnesty International Australia website
The site also featured a footer with structured links in sections, very similar to the first demo I showed you.
The footer from the same site
So I was able to use this technique to implement the basic menu. But I could take it much further, by adding supplementary content to the footer links hidden in the footer. The thumbnails and long descriptions of each menu links is still present in the footer, but you can only the main links themselves. The difference is just CSS — when the lists of links are in the footer, the additional content is invisible; when they’re in the mega menu, it’s made visible and restyled.
Visit the Amnesty International Australia website to see this in action.
You can also download a demo zip file if you’d like to play with the idea some more. It’s an idea that could be extended in many ways; in theory, any kind of dynamic content could be designed in this way — sourcing its data from another part of the page, where it exists in a different form.