By James Edwards

The Footer’s the Menu

By James Edwards

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.
  • Generate the menus on the fly. The submenu content is created as required, from configuration data in JavaScript, and appended or removed from the top-level triggers as necessary. The problem with this approach is that the content is then inaccessible without scripting, or in browsers that don’t support or fire the triggering events. This solution relies on other forms of navigation (such as a sitemap) to make up for the shortfall in content.

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.

  • Terri Orlowski

    This looks interesting. I can’t wait to put it to use in a project.

  • This idea always seemed logical to me since the main navigation comes after the content. That’s great for screen readers and SEO. I used it a lot but rarely saw it adopted elsewhere?

    An additional benefit is that you also experience fewer positioning and z-index issues because content at the bottom of the HTML is moved to the top of the page and is above everything else. That’s ideal for a drop-down menu.

  • catbarnes

    Really helpful article, thank you so much for sharing + demo file. Beautiful work for Amnesty International. Congrats!

  • sylvain.picker

    I often see “Graceful Degradation” and “Universal Accesibility” as pipe dreams that are impossible to implement in the real world. But this footer/menu idea is so good, it should be promoted by everybody.
    Navigation after content also helps google and other search-engine to better understand and classify your content.
    Many thanks James.

  • Thought, would see some more examples in OptimalWorks, but nevertheless a very helpful article. Thanks.

    Partha Bhattacharya

  • Gerard

    The Amnesty International Australia website menu only works with javascript enabled.

  • arts-multimedia

    The only problem I see with this approach is that the main links show up twice in the document which is rather tedious for screen readers. Semantically correct would be to have the navigation appear in html at the bottom and have the main links at the top also called with javascript.
    That way, you have no repetition. But it is a good idea, absolutely.

  • Jorge Fernandes

    Hi James,

    At first glance the solution seemed me awesome! But then… when I tried it with screenreader I notice: the solution split the menu in two parts. The main options are at top and the suboptions are at bottom. The problem is how the screenreader user know that, for example, the option “Home” have suboptions? When he/she press the “Home” at the top, open the “Home” page.

    When we have a list with nested lists, we have an immediate structural relation between options and suboptions, programmaticaly (like WCAG 2.0 say) recognised by screenreaders. With your solution we don’t.

    My problem is: how to structural/semantic relate the options of top with suboptions at bottom?

    I thought in bookmarks. Something like:

    At top:
    At Bottom:

    But with this solution we gain a relation between menu main options and footer suboptions menu, but we loose the link to pages of main options. Hmmm!

    Maybe two links at the option menu. Something like:
    At top:


    The text “submenu” could be an image (less visual intrusive) with an alt=”Home submenu”

    What do you think of this?

    –Jorge Fernandes

    • how to structural/semantic relate the options? With headings — headings navigation has been shown time and again to be among the most effective ways to navigate in screenreaders, and consequently an ideal way of associating and structuring information.

      It doens’t *really* matter that there’s no direct, explicit association between the top-nav items and the footer links; the point is that all the information is there in an easy to use and understand form.

  • @orebaba – I don’t know what you mean by “more examples in OptimalWorks” ?

    @Gerard – naturally, the dropdown menus only work with JS enabled, as they should. But the point is, the links that are the content of those menus *are* accessible without JS – they’re there for everybody.

    I stress – dynamic menus like that absolutely must not work without JS enabled; there’s more about that in the “right way to make a dropdown menu” post I linked to.

    @arts-multimedia – where’s the repetition? The top-level of links is at the top; the footer contains the sub-links, but doesn’t repeat the top-level.

  • Tim

    FYI, the IE6 text tooltip says “Internet Explorr 6”

  • The amnesty international site looks amazing

  • How could I miss that !
    I did the exact opposite several times : cloning the main navigation to get the footer menu.
    Of course your proposition is better ! I was thinking that now, I just had to convince a designer to put such an ugly footer in its PSD but he doesn’t need to, as I can put the sub-menu contents as display:none into the footer !

  • Good idea. But I partly disagree with what you wrote about the “Generate the menus on the fly” solution. You wrote:

    The problem with this approach is that the content is then inaccessible without scripting, or in browsers that don’t support or fire the triggering events. This solution relies on other forms of navigation (such as a sitemap) to make up for the shortfall in content.

    If you do your dropdown menus the right way, then you should make sure the top-level items are links and you have good index pages for each top-level category. The submenus are there for quicker access to content, and that’s it. If a user has JavaScript disabled or is on a touchscreen device, he won’t see the submenu but that’s no big deal. Then, it’s not an issue if the submenu content comes from a JavaScript object rather than from the HTML content.

    For the Amnesty International Australia website, you could have the short list of links in the footer (no article teasers and illustrations hidden with CSS), and the dropdown content in a JavaScript object.

  • Precision: what I disagree with in the quoted text is not what is stated, but:

    a. The idea that providing access through other means is A Bad Thing. It doesn’t have to be.
    b. The idea that, if the dropdown cannot be seen or used, the other means of navigation available will be remote, barely usable stuff like a sitemap. No, make sure you have a good site structure and top level items are links, and you’re fine, no big loss in usability.

    You have a standard, effective navigation in HTML, then you use JavaScript to enrich that navigation, without clobbering search engines with the richer version. What’s not to love? :)

    • I agree, but I also think that providing the same means of accessing information is the ideal, even though providing it through other means is perfectly equivalent.

      The sitemap was just an example, it’s totally not a catch-all solution.

      Ultimately, isn’t it better that the links you want are already there, rather than one click away?

  • @Craig : I looked at your job on Amnesty, do you think your additional content about the links (the photos and the small digest after the link) are taken into account by search engines ?
    I’m asking this because they bear a “display:none”, and as far as I know, search engines don’t index such contents…
    Maybe it’s off topic but as we’re trying to be everybody friendly…

    • Hi McBenny,

      Actually, it was James who worked on Amnesty.

      Search engines don’t ignore elements with “display:none”. They can’t — they don’t parse CSS or JavaScript.

      However, some screen readers ignore such elements — even if JS eventually shows the box. If that’s a problem, you’d be advised to move the element off-screen to hide it, e.g. “margin-left:-9999px;”, then re-show it accordingly.

      • That’s exactly why I used display:none, so that it would be hidden from everyone, including screen readers, for whom it’s superfluous information in its original context.

Get the latest in Front-end, once a week, for free.