govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
Tabbed navigation
What
Use tabbed navigation to help users move between pages within a section of your service.
See also: Tabbed panel
Why
Tabs are used for navigation on many GOV.UK services.
For example:
- Companies House
- GOV.UK Notify
- GOV.UK Registers
- GOV.UK Pay
See the comments below for examples.
Anything else
Examples of the variation found in tabs on GOV.UK services:
Find and compare schools in England

GOV.UK Pay


GOV.UK PaaS

GOV.UK Notify

Charity Commission

DWP's internal “Support for Check Your State Pension” service currently uses tabbed navigation but they are changing to a sub nav that doesn't look like tabs.
They didn't necessarily see an issue with tabbed navigation, but their thinking is that for consistency, over time, the user should expect a certain behaviour when clicking a tab to when clicking a sub-nav item - so it was more a design decision rather than a fail in UR
Companies House
They’re links styled to look like tabs. I wasn’t working on the service at the start, but I’m fairly sure they were modelled on the BBC News websites ‘tabs’. They did a lot of research into the labelling of them (card sorting exercises with over 500 of our users). The Digital Accessibility Centre (DAC) recently did an audit, and the tabs weren’t an issue.
To expand on Adam's comment, there's a subtle difference between a sub-nav and tabs. At DWP, we did a whole workshop on tabs, and the definitions that came out of that were that tabs should be related content, and used as a means to breakup what would otherwise be a very long page.
If the content is unrelated or it would not make sense on the same page, then a seperate sub-nav component would be better.
I think we have to be careful with context. The interactions with any component should be consistent so users feel comfortable with them each time they see them. Rather than it being easy for the designer to just use tabs because they sort of look like a nav.
To me a sub nav relates to the thing “above it” in the hierarchy.
Take the following screenshot. Overview, Filing History and People are sub nav items relating to the company. And Officers and Persons With Significant Control are tertiary nav items relating to People.
I know there's a separate ticket for navigation in general and I think tabbed navigation may well be redundant should we get that right.

Worth copying @abbott567 comment regarding tabbed navigation here:
Probably worth mentioning on here that our stance on tabs at DWP was not to have both tabbed navigation and javascript tabs with the same styling. The reason being that if they look the same, the expected behaviour is the same, but it's not.
We opted to keep our tabs styling for the progressive enhanced version, and for our tabbed navigation, we are going to switch to a component with different styling. This way you don't see two things that look identical and have an inconsistent experience with how they work.
Also, the user need for having the JS tabs over the tabbed nav fell out of research we did on Bereavement, where our agents were getting disorientated. The tabs were a little way down the page, and when we used the non-js version it would pop them back to the top and they would lose their place.
We also tried doing it with anchor links to the ID's, but it never quite puts them back to the same place. It's still jarring, and it was creating unnecessary cognitive load to try and orientate themselves again.
I share Craig's concerns on this. To add a couple of notes:
A (sighted) keyboard user would have to learn how to operate the different types of tabs which wouldn't be apparent if they look the same. The user would have to interact and see what happens and be okay with whatever does or doesn't happen based on their expectations.
Perhaps this isn't a big deal, but my approach would be to avoid a potential problem at the outset.
Note: I've spoken about my concerns with @joelanman but wanted to get these down here so they're not lost in future iterations.
Thanks both of you, this is a really useful discussion. Can I try and summarise your position, to check that I’ve understood it?…
Tabbed panels and tabbed navigation work slightly differently:
- the keyboard interactions are different
- users of tabbed navigation may experience vertical jumping
- tabbed navigation may be slower, as each page has to load
Because of this, you’re concerned that styling them to look the same may confuse some users. Instead, you’d prefer to replace the tabbed navigation component with a secondary navigation component.
Does that sound right?
Yes.
But on the flipside, and as you know, tabbed navigation is in use and is, to my knowledge, well understood by users (at least in isolation).
I think it would be worth you or @joelanman noting the concerns around not having tabbed navigation as an option in the design system to balance out and record the other point of view which I think is more than valid.
I would also like to note, that despite my concerns, we could offer the tabbed navigation component as experimental; and we could list the various concerns and gather research across government once it's in use.
Hey Tim, that summary sounds right for what I was getting at. 😊
An example of subnav/tabbed navigation

I think it would be worth you or @joelanman noting the concerns around not having tabbed navigation as an option in the design system
So the need here is 'I need to know I'm in a section, and what other sections are available'. I think it works best if the sections are related in some way.
Personally I'd call that Tabbed Navigation - even if the visual style doesn't look 100% like real tabs, as in the example above.
In contrast, 'Navigation' doesn't necessarily deal in 'sections' or telling you which one is selected - it can just be links to useful, unrelated places.
We could call it Navigation Menu (or similar) to make it agnostic of its visual treatment (which may differ with/without JS or in small/big screens).
Here is an approach we may adopt for JUI service. This is just a quick visual mockup I've done now.
A simple horizontal representation for desktop and a vertical switch for mobile.
Thanks all - I think we're starting to converge on a design. With a small tweak to the selected tab style we can have a system-wide convention - selected things have a blue bar. Here are some examples:

The examples above are more about visual style, not appropriate use. What do you think?
@timpaul a subtle and lovely addition is the blue highlight for the active tab.
@timpaul Those are great and exactly what I had in mind, thanks!
Quick thought while I have it: sometimes these sections are a single page each (like companies house), sometimes they are multiple pages, with sub-navigation (like the GOV.UK Design System). The only possibly useful distinction I can think of is in the single page case, there's no user need to click the current tab again. In the multi-page version, clicking the current tab could take you back to that tabs 'home' page.
@timpaul love the subtle highlight. Great work
Cheers all! I should confess I stole the idea from strava.com ;-)
@joelanman - same goes for secondary navigation too. It raises the question - should the selected nav item always be a link, even if it only goes to the current page? I might move this question and related ones over to the #76 Navigation pattern issue...
@timpaul I like it visually - they're nice! However one thing we've heard about tabs is people can miss the other tabs, and not realise they're clickable. In this design I think we're drawing even more attention to the selected tab (and using an 'interactive' link blue), whereas the other, interactive tabs are all greyscale.
Here's some proof regarding @joelanman's comment around needing a grey background on inactive tabs:
https://github.com/hmrc/design-patterns/issues/81#issuecomment-342185053
Check out the sub nav underneath the search box—look familiar? :)

Here is another one :)
Check out the lovely blue highlight :).

Just noticed twitter's is very similar too
The Design System working group discussed this proposal on 24 May 2018.
There was a general consensus that styling navigation to look like tabs should be avoided, because it results in 2 components that look the same but behave differently. DWP are already moving away from using tabs as navigation.
Whilst it’s true that navigation styled as tabs can be made to work in the context of a specific service, the group agreed that there was probably another equally effective visual treatment that did not introduce the potential confusion, and that a design system should aim to avoid potential misuse.
The group also discussed issues with the positioning of secondary navigation below page content, as it forces screenreader users to navigate repeatedly past that content across multiple pages.
One member mentioned a blog post from GDS about adding labels to navigation to aid screenreader users.
My service is using the tab component.
If the pages are short, switching between pages causes the tabs to jump up and down.
.
I feel like this is probably a similar issue to @adamsilver's tweet a few weeks back about things jumping when closing an accordion.
My ideal would be that users using the tabs do not see them jump when swapping between them - I feel like it's rather jarring. It's also less than ideal if you're quickly switching between two tabs - you might have have the tabs moving by quite a large amount.

Example from my prototype - I've aligned one of the categories to the right as it's unlike the others. About account admin vs day to day work.
Maybe we should close this in favour of https://github.com/alphagov/govuk-design-system-backlog/issues/151 since I think we've agreed it should not look like tabs.