-
Notifications
You must be signed in to change notification settings - Fork 2
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
Comments
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 |
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:
|
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?…
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. 😊 |
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). |
@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: |
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. |
Maybe we should close this in favour of #151 since I think we've agreed it should not look like tabs. |
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:
One WCAG AAA issue raisedWhen in mobile mode, tabs must have headings for each tab section.
More detail in this issue: |
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:
See the comments below for examples.
Anything else
The text was updated successfully, but these errors were encountered: