Tabs

[govuk-design-system]

Tabs

Use this issue to discuss this pattern in the GOV.UK Design System.

Contributors

• @adamsilver
• @trevorsaint

Related components

• Tabbed navigation #5916 Tabbed navigation

Related links

• Tabs in Home Office design system
• Tabs in HMRC design patterns
• Tabs in Rural Payments Styleguide
• Tabs in Reform pattern library
• Tabs discussion in Dropbox Paper
• Tabs in the Citizen's Advice Design System
• Neilsen Norman guidance on tabs
• Léonie Watson blog post on accessibility testing, including tabs

[timpaul]

@adamsilver and @trevorsaint have very kindly agreed to develop this component, using their work on tabs in the Reform pattern library. The Sass and JavaScript for their tab component is available on GitHub.

[timpaul]

@adamsilver and @trevorsaint have reported that the original version of the component is being used successfully in the following services (amongst others):

Criminal Justice Services (CPP)

• Prosecutors
• Legal Advisers
• Court Administrators
• Online reporting (SJP performance data)

Judiciary UI internal systems (HMCTS)

• Divorce
• Civil Money Claims
• Financial Remedy
• Continuous Online Resolution (COR)
• Court Case Data (CCD)

Rural Payments (Defra)

[timpaul]

Tabs component criteria

Following 2 discussions with @adamsilver and @trevorsaint we've agreed that, in addition to meeting the Design System criteria, this component will meet the following additional criteria:

Coding criteria

The tabs component must:

• be built using GOV.UK Frontend
• follow the GOV.UK Frontend coding standards
• be tested with these browsers
• be tested with these assistive technologies

Design criteria

The tabs component must:

• be based on existing elements from the Design System
• be operable with a keyboard
• be usable on a small-screened device
• degrade gracefully if JavaScript is not available
• handle cases where tabs run across multiple lines
• handle cases where the user changes their default colours
• let users bookmark the selected tab
• not have a visited state
• appear in the browser history
• have an optional bordered variant

Guidance criteria

The tabs component guidance must:

• follow the GOV.UK Design System content pattern
• follow the GOV.UK style guide

Research criteria

The component must have been tested with a representative range of users in a prototype or live service.

Accessibility criteria

The tabs component guidance must:

• be focusable with a keyboard
• indicate when a tab has keyboard focus
• inform the user that it is a tab
• inform the user if it is selected
• inform the user about the label of the tab
• inform the user about the total number of tabs
• inform the user about the number of the current tab out of the total number tabs
• allow to switch between tabs using arrow keys

[joelanman]

I'm wondering if it's helpful to split this work into smaller chunks, something like:

1. Visual design, HTML, guidance. The tabs are links to page where that tab is selected.
2. JavaScript, ARIA (if needed), history API

I think 1. might be significantly easier to do, and easier to get through the process and deliver value quickly. We could then enhance it to 2.

[timpaul]

@trevorsaint and @adamsilver - what do you think? Would that help, or do you think that both chunks will be ready in good time?

[adamsilver]

We've already tackled all of those things now and we're close to finishing V1 (subject to crit etc).

[joelanman]

We just had a quick discussion about this on the team - to try and summarise (these are all just thoughts and not a steer in any particular direction):

It might be tricky to convey when teams should use version 1 (full page navigation, tabs link to content on separate pages) and version 2 (all content on one page, enhanced with javascript to switch between them).

Version 1 seems to be in wide use around government.

Version 1 is useful when the pages are quite large, and combining them in version 2 would mean users download a lot of data they don't necessarily need.

We need to be careful to only use ARIA on version 2, it would be incorrect on version 1.

[timpaul]

Following a productive discussion with @adamsilver and @trevorsaint we've agreed the following:

• we'll rename this component from 'tabs' to 'tabbed panel'
• the default style will now be bordered
• this component is now specifically for bordered tabbed panels
• we'll create a new component called 'tabbed navigation'
• this is for the other use case, the non-JS tabs
• for now, the visual style of both components will be the same (without the border for tabbed navigation)
• we may iterate the style of tabbed navigation if we find it's confusing to users

[joelanman]

Léonie Watson blog post on accessibility testing, including tabs via @accessiblewebuk

[accessiblewebuk]

Also of interest https://inclusive-components.design/tabbed-interfaces/

[adamsilver]

DWP using JS tabbed interfaces with research showing the need and proof of accessibility testing
https://github.com/dwp/design-examples/tree/master/tabs

[adamsilver]

DWP draft guidance
https://docs.google.com/document/d/1nalvO7QwNiSyX8aVYeM6U1iNtB9-UDMNNjsHFhS4u-U/edit#heading=h.u45atcpl9klz

[adamsilver]

These DWP internal services use tabbed panels with JS:

• Manage Bereavement Support Payment
• Access to Work Integrated System

[abbott567]

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]

Some of the Accordion guidance, I think, is relevant to Tabs.

https://paper.dropbox.com/doc/Accordions-4lnTjyNru2mN1XXjA1Xf3

[joelanman]

thats good to know but it doesn't really answer the question, especially when it appears to be recommended against in that link:

If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.

[hezjbunch]

When trying to use it via keyboard only with JAWS or NVDA screenreader running, it does not appear possible to use the down arrow to navigate into any non-interactive content on the tabs because the down arrow is moving focus to the next tab.

@hezjbunch, I can verify there is an issue with NVDA. But I cannot reproduce this with our version of JAWS. Can you please share with us the JAWS version and browser you used when you encountered that?

Apologies for late response. We have JAWS 2022 on POISE machines

[selfthinker]

@hezjbunch, I can verify there is an issue with NVDA. But I cannot reproduce this with our version of JAWS. Can you please share with us the JAWS version and browser you used when you encountered that?

Apologies for late response. We have JAWS 2022 on POISE machines

Thanks. I can confirm the issue is also in JAWS 2022 and all older JAWS versions that I could find (down to JAWS 16), but not in JAWS 2023 (with which I had initially tested). I will update the related issue accordingly.

[simonWheatcroft]

I am a full-time screen reader user. With NVDA version 2021.1 (The version we have on POIS). The interaction of the tabs is as expected.

I enter focus mode for the interaction. Select the tab I want using right and left arrow (up and down do switch tabs as well).
To read the tabs content, I switch to document mode. Down arrow then reads the tabs content.
JAWS is a little trickier on 2022. It is usable by switching between virtual cursor on and off.

I will test on the latest version of NVDA and JAWS when I can get to a personal device.

[selfthinker]

I enter focus mode for the interaction. Select the tab I want using right and left arrow (up and down do switch tabs as well). To read the tabs content, I switch to document mode. Down arrow then reads the tabs content.

That just made me realise that I didn't notice when I tested that the screen reader would go into focus/forms mode automatically. I guess I heard the beep but didn't pay attention to it. This makes much more sense now.
I can confirm that getting out of focus/forms mode "fixes" what I had perceived as a problem. And I can also confirm that what I saw as a fix in JAWS 2023 is that that version doesn't automatically go into focus/forms mode anymore when it encounters these tabs.

Thanks for checking this and describing your interaction.

I guess it is working as intended after all. (With the exception of NVDA and Firefox due to an additional other bug.)

[geoff-bell]

I've been looking in to using the tabs component on our service (Alcohol Duty Reform), and when I've been using it, I've noticed that the component uses JavaScript - I was wondering if anyone is able to clarify the reasons for using JavaScript with this component, when it can be done with just CSS? Is it for accessibility?

The main problem with using JavaScript with the component is obviously how it's then displayed if JS is disabled, whereas using just CSS would negate this.

Thanks

[owenatgov]

Hi @geoff-bell 👋🏻

From some quick desk research, I'm assuming you're referring to using radio inputs and labels as functional hooks for css to manage switching between tab views instead of click events in js, like this codepen. The rest of this comment will be based on that. If there's another solution I've missed, I'd like to hear it!

The history of this component is a bit tricky to track as it pre-dates us moving 100% to github to document our tech and design history so a chunk of this will be speculation. I suspect the reason this was originally built in js was browser support. Back when we supported older versions of IE, the css necessary for this to work wasn't supported by older browsers. In addition because we're styling something that has a specific intent (an input for a web form) it's difficult to progressively enhance into, say, just headings and content because older browsers will steer towards defaulting to how that element normally looks.

It's probably possible now that we've dropped IE support from 5.0, however it's something I expect we'd still want to investigate thoroughly. It'd require a lot of maintinence to ensure a smooth screen reader experience (which is already a known issue with our tabs currently) considering we're breaking semantic rules, and we'd still want to make sure it doesn't make services impossible to interpret or use for the very small percentage of old browser users.

It's also worth noting that tabs should be considered a content enhancement rather than a critical piece of your design and content infrastructure. When js is disabled or fails to load they default back to basic headings and content without js, similar to our accordion component. Personally speaking, I'm wary of using radio inputs against their semantic intent and introducing risk, especially for accessibility, just so that we don't have to ship js.

Tabs are one of our more advanced components that we're hoping to revisit soon and we can keep this in mind when we get to it.

[geoff-bell]

Hi @owenatgov - thanks for your quick response! That makes perfect sense and that was the method I was referring to.

Thanks again for your reply!

[james-baker-moj]

Hi, we have run into a small issue when combining tabs with notification banners. Apologies if this is not the correct forum.
When a user leaves from a tab to some other page we'd like to return them to that same tab, this is possible by using the anchor in the URL to deep link into the tab.
However, if the page also has a notification banner, e.g., success, then we jump to the content of the tab and the content of the notification banner is hidden, this is because the notification banner is directly above the h1 as per GDS-guidelines. If we return to the default tab (i.e. no anchor in URL) then the notification banner is correctly focused,.
So far we have been unable to work around this as both components use javascript without any way to hook into the events for customisation (at least it's beyond my own capability :)).
My understanding of the tabs JS is that it selects either the tab matching the anchor in the URL or the 1st tab. If this could be expanded to include looking for a pre-selected tab (use govuk-tabs__list-item--selected?) then this would allow teams some control over this behaviour.
We can raise a PR for this but I wanted to gather some feedback first, I see there was a question about selecting non-default tabs a while back that didn't have an answer AFAIK. Thanks

[paulspellr]

Hi there! I have a quick question about this tab pattern from an accessibility perspective, which I don't think is answered in this thread but I may have missed it!

I just wondered if there was a particular reason why the border around the current tab and panel is rendered in such a low-contrast shade of grey?

My thinking was that the visual language giving users a cue that they are in a tab panel (and that the links alongside the current tab are other tabs) would be available to more users if this grey was just darkened down somewhat to hit a better contrast ratio than its current ~2:1. Whether that's taking it all the way down to match the near-black text shade, or even just darkening it down to something around #767676 to hit around 4.5:1 (surpassing the Non-Text Contrast minimum requirement of 3:1).

But I wasn't sure if there might be another reason from other research etc to explain the choice of grey shade. If not, consider this a suggestion 🙂

[TomRafferty]

Hi all, I hope you're doing well, happy Friday 🎉

I'm one of the devs from View and Change 😃

We're wondering if there is anything that can be done regarding the Tabs component, and the problem of the tabs wrapping/moving to a new line?
Essentially this issue is occurring for us somewhere in between mobile and desktop screens (tablets basically) - we discovered that on our setup (two tabs), if the tab label has >16 characters then the issue occurs at tablet resolutions such as 820px width (iPad air)

As not many of our users are actually using tablets (~0.7%) we wanted to avoid doing a content change as this would effect all users and would need to be researched and user tested.

We were able to partially fix it directly in the browser by overriding the div wrapper class govuk-grid-column-two-thirds with govuk-grid-column-two-thirds-from-desktop however, the issue does still persist at resolutions (widths between: 769px-832px)
Unfortunately we've had difficulty doing this in the codebase as it seems the CSS gets overridden

Our proposed solution to this would be to have these tablet resolutions use the mobile CSS i.e when the tabs become a list of links and their respective panels all display on the page sequentially. Or if possible some kind of system that can detect the tabs wrapping, and then moving to the mobile style.

[LucyGeddis]

Hi all,

Hope you are well. We recently had an accessibility audit and an issue was raised around confusing announcements associated with the tabs component which I wanted to make you aware of. When viewing the tabs on a mobile device, a screen reader reads outs the 'em-dash' which is displayed beside the tab name.

Please let me know if you need anymore details or if there is somewhere else I should raise this.

Thank you.

[NickColley]

Heya @LucyGeddis,

Thanks for letting us know...

If you know, could you let us know what the specific operating system for the mobile device was and what screen reader was being used e.g. talkback or voiceover or something else?

[LucyGeddis]

Hi @NickColley ,

These are the details for the mobile devices and screen readers used:

• Android 15 – Samsung Galaxy S22 – Chrome 150 – TalkBack
• iOS 26 – iPhone 13 – Safari 26 - VoiceOver

Many thanks.

[NickColley]

@LucyGeddis I have moved your report into an issue on the GOV.UK Frontend project repository for us to consider, thank you!