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 #138 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

[adamsilver]

Judicial case manager screenshots

With a cheeky example of sub nav too.

Big screens

Small screens

[adamsilver]

Court Case Data Screenshots

Big screen

Small screen

[adamsilver]

Bank holiday screenshots

Big screen

Small screen

[adamsilver]

Find a charity uses tabbed panels

http://beta.charitycommission.gov.uk/charity-details/?regid=219830&subid=0

Big screens

Small screens (broken)

[adamsilver]

Find and compare schools screenshots

Big screens

Small screens (broken)

[eserkansozer]

Hi! How can I possibly default select the second or the third tab? It seems when I set "govuk-tabs__list-item--selected" and "govuk-tabs__panel--hidden" classes accordingly to activate the second tab by default in HTML, it does not work as expected and resets it to the first tab during the page load.

Here is the live URL to the scenario I am working on (I am upgrading the tabs here to GOVUK Frontend version).

There is a validation error and user needs to see the tab where the error is.

[JOP-Temesis]

Hello,

Firstly I am very admiring of your work which has a real international scope

I must admit that tabs through the design pattern tablist/tabpanel/tabs are a choice that I recommend very rarely. As the design pattern role="menu", I find that this component has a desktop application ergonomy not adapted to a website. Indeed users are not always used to use arrows to select tabs. For that I prefer a component like this :

For the list of tabs

• Use a nav element around the list of tabs, with a role="navigation" attribute and a aria-label attribute populated with the title of the tabs component;
• Add an aria-current="true" attribute on the currently displayed tab link (and update it when the user activates another link in the tab list by either setting the value to “false” or by removing the attribute entirely, and then adding aria-current="true" to the new displayed tab link).

For each panel

• Add to each panel a tabindex="-1";
• Add to each panel a heading <hn> (visible or hidden with the sr-only class) matching the title of the tab;
• Add a link pointing back to the corresponding tab at the end of the content of each panel (always visible or visible only on keyboard focus), e.g. “Go back to XXX tab”;
• When a panel is not visible, it must be made invisible to all users with a hidden HTML attribute (added/removed in JS);
• When JS is disabled, all panels and the list of internal links must be visible.

the component has the advantage of working only with the TAB key

Among your user feedbacks, have you ever had any problems using the tab component?

cordially,
/J

[CharlotteDowns]

We have removed the 'Experimental' tag from components, patterns, and guidance in the Design System 😌.

The tag was being used on the tabs component to raise awareness that more research is needed to validate it. However, we recently published new guidance on how to share findings from users which we hope will make it easier to collect more information about how our Design System is being used across services.

If your team has used this component please let us know 💪🏻.

[shabana-ali]

Hello,

Not an issue with the tab component itself but with the example containing tables. The tables are missing the <caption> tag. This may not be as much of an issue (for screen reader users) when there is a single table presented in the view but when viewing the tabs on a small screen / zoomed / no JavaScript (fallback version), multiple tables are presented making it more difficult for screen reader users to know what each data relates to (either navigating directly to the table of viewing it out-of-context, i.e. in rotor).

We advise adding the <caption> to each table but that this could be govuk-visually-hidden. This would cause a repetition for screen reader users due to the preceding heading.

An alternative may be to nest the heading in the <caption>. See AT investigation carried out by @adamliptrot-oc Tables captions and headings. However note:

• this does need to be checked and ensure it is supported by the listed AT (when last checked support had improved) https://www.gov.uk/service-manual/technology/testing-with-assistive-technologies
• this would only be applicable if there was no content needing to be added between the heading and table
• this would not work if multiple tables were present in a single tab (the grouping relationship of the tab would be lost)

[andrewscrivener]

Following a recent accessibility audit I'm looking for some advice on the ideal behaviour of the tab component.

Our page interaction is similar to the GOV.UK Design System. A user navigates through the page using the tab index, when they press enter to view the tab, the content is displayed but as the page reloads the focus is reset back to the first element on the page.

This has been flagged as an issue by the audit team;

...they are focused back to the top of the page, instead of focus remaining on the selected tab, which is not logical.

This does not comply with WCAG Level A 2.2:
2.4.3 Focus Order - https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html

We're not sure what we can do to ‘fix’ this. The issue here is that our service does a full page refresh when a user clicks any of the tabs. This resets the focus back to the start of the page. This requirement might make more sense if we were a single-page Web application.

Is the intention here to have the active tab always take the initial focus or only immediately after the user has switched tab? The former seems achievable but the latter would require some JavaScript to implement it.

Any guidance would be appreciated.

[joelanman]

@andrewscrivener the component in the design system does use JavaScript, and is not intended to load a new page:

https://design-system.service.gov.uk/components/tabs/

[andrewscrivener]

Ok thanks @joelanman I know the tabs use JavaScript. We'll alter the interaction to refrain from reloading the page and keep the focus on the tabs as opposed to resetting it to the top of the page like GOV.UK Design System.

[hezjbunch]

I don't know whether anyone has come across this issue before but I think there may be a problem with this component. 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. The guidance here - https://www.w3.org/WAI/ARIA/apg/patterns/tabs/#keyboardinteraction would seem to indicate that in a horizontal implementation of tabs, the up and down arrows should not be listened for thus enabling them to be used for browser scrolling or presumably when using a screenreader, they would allow the user to navigate the non-interactive content of the tab.

Please tell me if I am missing something here but it would seem to constitute a block to screenreader users.

[querkmachine]

Hi @hezjbunch, thanks for bringing this to our attention.

We aren't sure whether this specifically constitutes a 'block', insomuch as overriding any keyboard function is potentially blocking some function of a screen reader. The left and right arrow keys can sometimes be used to announce text letter-by-letter, for example, which also wouldn't be possible in this situation.

However it is notable that the WAI pattern specifically seems to advise against what we're currently doing, and that does lead me to think that we should change how it works. I'm consulting with the other devs and our accessibility specialist on whether and how we want to handle this.

[hezjbunch]

Hi, thanks for getting back to me so quickly. I think it would pose a problem mostly for blind users because they may not be aware that there is any content there without using the read all function of the screenreader to read the entire page. Anyway, I'm sure there are some changes that could be made in order to make it more accessible for keyboard only screenreader users.

[selfthinker]

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?

[selfthinker]

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.

I've found that this is a known issue. See alphagov/govuk-frontend#860. I've added a comment with more information to that issue as it seems to be a bit misunderstood by people.

[joelanman]

why are we listening for up and down button presses at all, especially if it causes an issue? The tabs are always displayed horizontally

[selfthinker]

why are we listening for up and down button presses at all, especially if it causes an issue? The tabs are always displayed horizontally

It doesn't cause an issue. The issue is independent of us listening to up and down key presses. I know, it appears as if that's the issue but it isn't. (Check the link from my previous comment.) For example, the same problem (presenting slightly differently) happens with the tabs pattern in WAI's Authoring Practice Guide even though they are not listening for up and down arrow presses.

[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!