Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tabbed navigation #138

Open
timpaul opened this issue May 9, 2018 · 31 comments
Open

Tabbed navigation #138

timpaul opened this issue May 9, 2018 · 31 comments
Assignees
Labels
component Goes in the 'Components' section of the Design System

Comments

@timpaul
Copy link
Contributor

timpaul commented May 9, 2018

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

@timpaul
Copy link
Contributor Author

timpaul commented May 9, 2018

Examples of the variation found in tabs on GOV.UK services:

Find and compare schools in England

image

GOV.UK Pay

image

image

GOV.UK PaaS

image

GOV.UK Notify

image

Charity Commission

image

This was referenced May 9, 2018
@adamsilver
Copy link

adamsilver commented May 11, 2018

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

@jfranciswebdesign
Copy link

Companies House

image
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.

@abbott567
Copy link

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.

@adamsilver
Copy link

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.

image

@adamsilver
Copy link

adamsilver commented May 11, 2018

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.

@adamsilver
Copy link

adamsilver commented May 11, 2018

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.

@timpaul
Copy link
Contributor Author

timpaul commented May 11, 2018

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?

@adamsilver
Copy link

adamsilver commented May 11, 2018

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.

@abbott567
Copy link

Hey Tim, that summary sounds right for what I was getting at. 😊

@adamsilver
Copy link

adamsilver commented May 14, 2018

An example of subnav/tabbed navigation

image

@joelanman
Copy link
Contributor

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.

@adamsilver
Copy link

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).

@trevorsaint
Copy link

Here is an approach we may adopt for JUI service. This is just a quick visual mockup I've done now.

image

A simple horizontal representation for desktop and a vertical switch for mobile.

@timpaul
Copy link
Contributor Author

timpaul commented May 14, 2018

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:

image

The examples above are more about visual style, not appropriate use. What do you think?

@trevorsaint
Copy link

@timpaul a subtle and lovely addition is the blue highlight for the active tab.

@adamsilver
Copy link

adamsilver commented May 14, 2018

@timpaul Those are great and exactly what I had in mind, thanks!

@joelanman
Copy link
Contributor

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.

@abbott567
Copy link

@timpaul love the subtle highlight. Great work

@timpaul
Copy link
Contributor Author

timpaul commented May 14, 2018

Cheers all! I should confess I stole the idea from strava.com ;-)

@timpaul
Copy link
Contributor Author

timpaul commented May 14, 2018

@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...

@joelanman
Copy link
Contributor

@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.

@adamsilver
Copy link

Here's some proof regarding @joelanman's comment around needing a grey background on inactive tabs:

hmrc/design-patterns#81 (comment)

@adamsilver
Copy link

adamsilver commented May 14, 2018

Check out the sub nav underneath the search box—look familiar? :)

image

@trevorsaint
Copy link

Here is another one :)

image

Check out the lovely blue highlight :).

@abbott567
Copy link

image

Just noticed twitter's is very similar too

@timpaul timpaul added the component Goes in the 'Components' section of the Design System label May 21, 2018
@timpaul
Copy link
Contributor Author

timpaul commented May 24, 2018

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.

@edwardhorsford
Copy link

My service is using the tab component.

If the pages are short, switching between pages causes the tabs to jump up and down.
tabs-scrolling.

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.

@edwardhorsford
Copy link

edwardhorsford commented Mar 1, 2019

screenshot 2019-03-01 at 16 49 41

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.

@joelanman
Copy link
Contributor

Maybe we should close this in favour of #151 since I think we've agreed it should not look like tabs.

@CharlotteDowns
Copy link

We ran an external accessibility audit for some of the components and patterns in GOV.UK Frontend in May 2023. In that audit, we included an example of the Tabs component. We’re adding results from that audit here so that we can:

  • document, discuss and address the findings
  • inform future contributors of the findings

One WCAG AAA issue raised

When in mobile mode, tabs must have headings for each tab section.

The two tab panels presented for users on the start page, have not been provided with headings to introduce the sections of content. This caused more of an issue in the mobile view as the different sections were not clear.
Although when contained within tab panels, when viewing on a desktop, the sections of content were separable from one another and other content on the page. The lack of section headings in the alternative view did not enable users of screen reading assistive technologies to easily understand the purpose of the skip links.
This can also be confusing for other users when viewing the page with magnifying options as the skip links indicate the sections of content they will direct the user to, however, there are no headings to relate those links to the specific sections of content when viewing in this way.

More detail in this issue:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component Goes in the 'Components' section of the Design System
Development

No branches or pull requests

8 participants