The Australian Government coat of Arms

Communities of practice

Side nav



Admin note

For an easier to track conversation we’ve split this topic into two components and moved some posts:


For me, the slight indent isn’t clear enough. It would probably make more sense if you were using it and the items were initially hidden. I do like the side bar element for the active/hover/focus item, it would be nice to have the Chevrons next to each item indicating which will expand to give the user more choices and which take you directly to a page.

I saw an article in not that long ago about Nav menus and their guidance was to aim around 7, not much more. I totally get that our sites are way more complex than that, but surely there is a way to arrange the pages into more manageable options so that the user is looking at 7 options instead of 21, then those 7 giving a further 7 options etc?

The project I’m working is quite small, it’s currently at 67 pages but none of the Navigation panes have more than 6 items. We manage this by using hub styled pages - rather than direct from the Nav - this keeps the Nav really simple, but also assists users to find the information that they want quickly without getting lost on the site. The same Navigation panel is available on every page, goes to a Hub page and from the Hub page you access the topical pages, so it’s basically only a two level structure.

I imagine on a more complex site collection, you could do the same, but tier the first level to have it’s own nav that is consistent across tier 2 and 3 pages. So for Centrelink for example, your tier 1’s might be families or students or newstart - then once the user selects their tier 1, its like being in a site dedicated to that with the option of returning to the Main page to change tier1?

Couldn’t some of those topics in the 21 items example be grouped so that the user isn’t presented with so many straight up? Could you have a longer web page with more content in an accordion style system so that grouped content is still separate, but easy to find?

I’m still a bit new to all this, but it feels like there should be some basic boundaries in place from a content management point of view so that navigation and usability can be kept simple and user friendly.


Also, just on a visual note, could the second and third tiers be a slight tint of the first tier, just so that they are visually differentiated?


Thanks for the feedback @AnitaWatters

The Guides team are putting this one through some tests soon. So that will be helpful in identifying any issues.

I tried this design, which i think is visually nicer, and shows the tiers much better.
But I’m worried it doesn’t address WCAG 2.1: 1.4.1 Use of color

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

I think it could be argued that the list design, and position of the element distinguishes it as navigation, but I think it would need something stronger to convey it’s function.
(I tried all underlined links, but it looks way to visually busy and hard to read.)


That’s definitely better with the chevrons and the indent and line. I still think a very slight change to the colour would help. WCAG says that it can’t be the only thing that conveys a meaning, which is very important for people with colour blindness or poor vision, but I’m also thinking of it from the point of view of people with other cognitive processing issues. I’m not thinking of a large visual change, I’m thinking something very subtle. It will depend what the existing contrast is for how much room you have to play with in terms of contrast. I’ll have a play with it when I get to work.

Totally agree that the underline makes it to busy.

A very slight bottom border on all but the last child element might help it to look more button like as well.

I’m thinking that this would be used with a contrasting background to the main page content too? If it’s not some sort of border to frame the Nav element might be useful, possibly with a very gentle shadow?


Thanks Anita. It’s difficult to visualise what you’re describing, maybe you could contribute some mockups?


I cant get into GitHub at work, or mock on my phone - so this is kinda what I was thinking. Originally I thought to go a tad lighter, but the color changes to a bit of a green tone when it’s lightened so I went darker instead. The dotted line on this version separates a heading but you get the idea, it could be used on all but the last item on the list so that you still get the normal border contrasting against the page background with a slight shadow to lift it off the page. There is three different colors used in the background of the nav, I thought the darkest for the third layer, not the active, but was trying to copy your layout quickly in Dreamweaver. I would have put a line under the hover event but I’ve got some conflicting CSS and I need to do something else real quick…



I know it’s a quick mock (good job though :D) but I can barely tell the difference on my mac between the background colours of the most-indented levels and the levels above. Maybe no need for the graded background changes, except for emphasising the active link?


Hi @podgkin we have this too for Digital Guides though our beta site is currently statically generated (we’re likely to migrate to GovCMS or similar in the coming months). Without getting too technical, we have a topic weighting system so that each page has a unique weight, (e.g. “10, 20, 40…”) combined with the folder location of the related files. The combination of the two determines the display order in the secondary nav menu. Though it’s a manual process at the moment, our content designers have a good system for adding and updating content so that the hierarchy is maintained. We’d possibly adopt a taxonomy system or have a GUI to drag and drop the page order to achieve what we need when we’d upgrade to a CMS.

I reckon this pattern @treb and my team are working on could still apply to a tag-based or categorical menu but then it may not need to go so deep (just 1-2 layers). Depends of course on your needs :smiley: Given the backlog of new content for future Digital Guides, I see our whole architecture evolving again and I’m considering changing the global nav links to represent what I’m calling “buckets” or “pools” of the various content types we support. This would be to accommodate N number of categories but make nav choices easier whilst not having to trace every page back to an explicit parent category - especially where content may overlap.


This is great treb, I think for a first cut I would remove the arrows I really like how this can scale to many use cases.


We’ve deployed our new side nav to our beta site in time for some user research.

Our research focus isn’t specifically on the nav (that’s in a coming sprint) but I’ll share any insights we gain, related to the nav here.


So we have just deployed a secondary nav for all payments and services. There are a couple of design considerations worth mentioning

As mentioned before we have found the nav alone was not working for some people, particularly on mobile where it collapses into an accordion that can be easy to miss. We tested a LOT of different titles for “In this section”, and eventually found something like “Austudy topics” or “Austudy details” worked best, but no matter what we named it, people still weren’t groking the collapsed double menu thing.

The solution that did work was listing the child pages on the page itself. We originally went with a simple list but found it looked out of place and got confused with the body content. In the end we went with cards, since they were clearly distinct from the content. Now you could theoretically achieve this by referencing and linking the child pages within the content itself, and we did this in a few places, but it didn’t provide a consistent learnable interaction method and just wasn’t feasible for several thousand pages.

This approach of listing the children also aligns to our longer term mobile menu designs as shown previously here.

We haven’t yet changed the styling for sub items, though we would like to take another pass at it and really like the styles @treb posted above.


One thing that we’d appreciate some help with is the way we handle secondary menus for shared content.

Stand-alone shared content

This piece of content is shared between more than a dozen payments. editing it one place gives us great content development efficiencies and makes sure we don’t end up with multiple slightly different versions that diverge over time. This one isn’t even that highly shared, some pages are used in 50+ different places. Each of the payments are listed in a secondary nav so you can get back to the payment you can from.

in-context shared content

We have just released functionality that lets us display these shared pages in the context of the payment you’re looking at them from. This lets users methodically work through all the content in a payment without getting lost in other payments. It gives us a funky breadcrumb that actually means something, and a more meaningful title, It works great and tests really well.

The thing is that these in-context pages can’t fully replace their stand-alone versions. We can’t redirect people away from the stand-alone version, because if someone comes direct from Google there are a dozen different shared versions, and we don’t know which one to direct a user to. For the moment both versions are available, with the standalone version if you come from Google and a shared version if your browse the site.

The design problem
So the problem we have right now is the standalone version showing multiple parents in the secondary nav. We have tested a number of different ways to display this concept to users, different titles for the nav, multiple linked parents in the breadcrumb or title, putting it in the content or other interaction mechanisms. Our current feeling is we shouldn’t use the secondary nav metaphor to mean different things in different places, so we need a different component entirely.

This multi parent nav seems similar to the concept Alexandra mentioned of having a tag based nav. We’ve found our users tend to get lost in this system, lose context and struggle to define their problem space. This may be a problem with our implementation, or it may just be that each navigation element should only be used for one context and not mix metaphors. If anyone has thoughts, we’d be glad to hear them.


Feedback from our team on the nav design concept, we haven’t tested it, just ran it past about a dozen people:

  1. we all independently thought it was a scrolling mechanism. attaching the highlight indicator to the indentation line makes it look a hell of a lot like a scroll.
  2. The chevrons being restricted to items with children is a good idea for reducing ornamentation, but in this implementation it has the side effect of making the indents inconsistent. This makes the active menu trail a little tricky to follow, some assumed the most indented item was the current item.
  3. It looks a bit like a list, if we didn’t tell people what it was, they didn’t recognise it as a menu pattern.

Interesting concepts though, we’re happy to see this being worked on. I also suspect some of the confusion may come from the repetitive text. If the items each had real titles that might have provided some context.


Thanks @treb I am trying to implement this. Can you explain how this works?

I have a menu like this:

  • Home
  • About ( active trail )
    • Blah
    • Bing ( active trail )
      • Tomato ( active )
      • Potato
    • Boop
  • Contact

From what I can tell on the Tomato page I would see a sidebar like this:

  • About
    • Blah
    • Bing ( active trail )
      • Tomato ( active )
      • Potato
    • Boop

Clicking the About link takes me to the about page and it also expands and collapses the menu. I was thinking about changing this interaction as it’s confusing.

On mobile we can do something like In the About section which opens and closes the menu and nest the About title inside. On desktop we can leave the About title as a link and hide the In the About section.

I also noticed that the borders are full width. This causes odd issues in development and potentially makes it harder to identify levels of indentation. We currently add more padding left for each link inside a list and increase the indent for each nested list. This solution causes problems when active state text has to line up with sibling items. We don’t know how deep in the menu the active item is. So reseting, changing padding and adding borders causes problems with alignment and clean robust code.

I am going to investigate the problem mentioned above however if you have any ideas would be much appreciated :+1:


Hey friends,

I have been working with treb. You can view our version 0.1.0 of the local navigation here:

If anyone has any feedback it would be greatly appreciated. I am currently finishing off documentation for the website.


Getting a 404 from that link Alex


Thanks @podgkin updated the link now.


Looks like an improvement, I ran it past a couple of people:

  • the two uses of bold in different contexts as both a heading and and the active item may be confusing
  • The level three tree structure icons work well for us and we’d want them on level 2 items as well
  • Are the cousin items going to be expanded or is that just for the example?

We’re a pretty tech literate bunch so it would be worth testing this with some folks who have lower tech literacy.


There is an option to have as many deep as possible. Our guidance and default styles will support three levels.

Really keen to hear feedback around the heading and active items if they are confusing to users. Thanks for the initial feedback @podgkin!