The Australian Government coat of Arms

Communities of practice

Main nav



Conversation for the main navigation component.
Continued on from a pervious topic.

Also known as

  • Main navigation
  • Primary navigation
  • Horizontal navigation
  • Hamburger Menu


A way to navigate between high-level pages or areas of a website/service which works well on mobile and desktop.

You can also view the component page on our documentation site for the Main Navigation component.


We have a main nav in production that was loosely based on the ATO navigation and a secondary nav based on We tested the nav of DTA, govCMS, ATO and a few other departments using a task common to all agencies, and found the ATO nav worked well because it limited the number of options available on screen at any time. For contrast the default govCMS drop down navigation provided too many options, and the DTA navigation provided too few, the worst performing nav was our old site nav.

While the ATO style nav worked best for drilling down, particularly on mobile, we also found users didn’t understand the way the ATO nav splits up each item into “drill down” or “go to”, so we removed this functionality in our current live navigation.

Since launch we’ve found nav usage to be quite low, though sessions involving the navigation seem to be positive. The reason for low usage is that the navigation options are too high level to be useful, so once you’ve used it once you’re unlikely to need it again. Our nav lets you choose the cohort you’re a part of, but once you’re in an area dedicated to your cohort, its unlikely you’ll then change cohorts.

Side nav

Hi Folks, we’re rearchitecting our menu/nav component for our portals at Social Services as it’s a bit of a mess at the moment.

As it stands, we are using a multi-level navbar (3 levels?!!) which looks great on desktop, but we’re having accessibility issues in regards to it’s responsiveness when it’s mobile/dropdown view.

We use the first level for the branding, notifications, profile and logout buttons.
The second level we use for the actual navigation to pages.
Finally we have a third level that someone tacked on to benefit from the stickiness of the headers/navs.

Here’s our structure:

<div class="navbar navbar-fixed-medium-size navbar-inverse" role="banner">
    <div class="facs-nav-1st-level"></div>
    <div class="facs-nav-2nd-level"></div>
    <div class="facs-nav-3rd-level"></div>

with every item (it’s a lot more gross than this):

<div class="container-fluid container-fluid--max-width">
    <div class="row">
        <div class="navbar-static">
            <div class="navbar-collapse collapse" role="navigation" aria-label="site">
                <div class="nav navbar-nav" role="presentation">
                    <div class="menu-item">

Here it is on mobile:

and here it is on desktop:

The second level is scroll-able (as there’s lots of items), while the first level and third level do not.
As you can already start to see, this is being a bit of a headache, especially in regards to accessibility.
Tab order and keybindings are issues we are trying to address holistically.

Would love to see what others think about what should be in a navbar (such as branding) or what the tab order should be (should logout float down to the bottom of the menu/s?)


From our accessibility expert:

The basic pattern of behaviour should be, when focus is on the menu button/hamburger:

  • enter - opens menu and puts keyboard focus onto the first link
  • arrow/cursor keys - move focus up & down in menu wrapping at the top and bottom to stay within the menu, i.e. after arrow down on the last menu item the focus moves to the first item
  • tab - closes the menu and takes user to the next focusable element on the page
  • shift + tab - closes the menu and takes user to the preceding focusable element (the menu button)
  • escape - closes the menu and returns focus to the menu button


Currently looking into a pattern for main-nav that works across all the themes. I realised that using the text-colour as the active link border doesn’t work very well on light themes.

However using a background works pretty well. Also means that it has good contrast to the non-active state, and maintains the existing look that most teams using the system have implemented.

We’ve also been looking at how the mobile version for all themes might work.


@treb yeah that works: the styling is consistent with Side (secondary) navigation
Though I’m unsure how you’d fit multiple levels of nav, as shown in this mobile view, within each individual tab (the desktop version).


The tab style works well for linking to main sections within a site: where the tab represents one link only. Clicking on another tab goes to another main section of the site: and does not go against what a tab normally does, say to reveal a sub menu.

It’s a good pattern for the top-level hierarchy of a site.

What are people’s ideas about mega navs and where have they been unavoidable in support of their information architecture? I’m keen to know if people have tried something simpler like this tab pattern and found through testing that they needed something…meatier (with more options).


For the first cut of this component we don’t plan on supporting more than 1 level.

(However, totally happy for other teams to take a crack at a second level before we do)

This was just a quick copy-pasta from the side nav mock to see if the styles could be shared.
Sorry for making that confusing.


All good. It may lead to another discussion about optimising mobile menus: that they don’t necessarily have to go as broad or deep (context sensitive of course) as their desktop equivalents.


Hello :wave:t2: thanks for sharing your nav. Re. ‘Home - A’, ‘Grants - A’ and ‘Milestones - A’ are these alternative links in your prototype? I wasn’t sure why there were several similarly-named links.

When designing header systems, it’s good to think about arranging similar functions together. Your users, depending on what other systems they’re used to using, may expect menu links to be grouped together, utilities such as search and log in/log out together, and window dressing (brand marks etc) to bind it all together as part of the visual design.

Re. the profile log in/out in the top right: do the main menu links change if a user is signed in? If so, it may make sense to keep the profile functions separate, but nonetheless (if you decided to merge profile stuff with the red bar) you may want to limit your alternative nav choices and ensure profile actions are located in their own utilities sub-group. Here’s a really rough wireframe where nav + utilities can live together but are separated into two territories along the same bar.

I’m assuming based on the labels and proximity to one another that Organisation Profile and Personal Profile are related and aren’t nav links?


Latest update.

We’re going to be progressing this component using the functionality from the main menu on – as always, we’re open to feedback.


Hey everyone, after some back and forward with @treb we have come to this as a first draft:
Username: uikit
Password: uikit

We had to rethink the mobile application as we need to do a few things differently to the design system website. We don’t know how large the header is or what will be in it. To solve this problem we now open the whole mobile menu from the left. It has a similar aesthetic to material design.

Next steps are finishing the react component, polishing it up, browser/device and accessibility testing.

If anyone has some initial feedback I would love to hear it!

#13 thanks for sharing the update. Re this bit:

On Digital Guides, we’ve decided to promote the global search as a separate feature to the menu and rather than collapse the two together on small devices have two tabs, ‘Open search’ and ‘Open menu’.

Here’s our desktop header plus the main-nav:

The stack order for narrower viewports preserves the display order on desktop: Site ID, search, then the main nav, so when the search gets smooshed down, it is displayed before the menu tab like so:


The main nav and the search intentionally open independently of one another and wipe down and over the page content rather than push it down - the latter creates a jerky jump especially when the search box gets focus and an on-screen keyboard appears.

Even if we were to combine search with the main menu in a future iteration, I see less of a benefit in peeping out from the left to mask part of the page content to the right (over what we have now) during a search on a small viewport. I guess I’m aiming to maximise the room for displaying and interacting with the search box.
It’d be equally weird if the main nav did a side wipe and the search tab did a vertical wipe :grimacing:


I mean thats all down to implementation. I can imagine a lot of different ways this could work. The main thing you are seeing is a toggle to open the menu. There could be:

  • A seperate toggle to open the search and that interaction could be different
  • The search could be combined with the slide in panel
  • The search could just be shown and not hidden


Yeah true. Regarding what you could get out-of-the-box though, would the main-nav component be mainly the toggle link and also have a few variations for hide/show transitions (i.e. open wipe right/wipe left/wipe down) or would those sort of appearance options be left out of the component and for users to decide on their own?


For the first implementation it would slide in from the left. As it covers the whole area it might be a bit odd sliding in from the top/bottom. In from the right makes sense for websites where users read languages right to left, however that would be a lower priority as of right now.


Not sure if Discourse supports animated gifs but here goes :crossed_fingers:

I recorded our menu and search interactions to show how the wipe down/up works for our purposes on mobile (this one’s an iPhone 6).


During our development and design there were a few things we wanted to do:

  • Don’t change the height / size of other components ( header )
  • Use one set of semantic HTML
  • If you have to overlap the content with another element
    • You need to lock the scrolling on the page
    • Add a focus lock to the content area so
    • Escape key handler for closing the overlay
    • Add an overlay over the content, clicking the overlay closes the menu
  • Works without javascript enabled


Hey everyone, we are happy to announce that version 0.1.0 of the main navigation is now available. There are some improvements we are hoping to make before releasing a stable version 1.0.0 however we don’t want to stop that getting in the way of feedback and community input.

Improvements coming soon:

  • Seperate open and close into single functions that can be called independently
  • Able to theme the menu that slides in on mobile, currently the colour defaults to the menu on desktop.

Check it out :+1:

I am also working on the documentation page for today, hoping to have that out soon.


The documentation page is now live: