Tabs

[govuk-design-system]

Tabs

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

Contributors

• @adamsilver
• @trevorsaint

Related components

• 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

[Astra-Gal]

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

Correct me if I'm wrong, but is this JavaScript only listening for click events, and not keyup or keydown ones? I couldn't see anything there to handle moving keyboard focus from one tab to another using arrows, as in the WAI-ARIA examples (JavaScript source code here), which has keyboard event handlers, and uses roving tabindex to manage focus.

[trevorsaint]

@Astra-Gal GOV tabs have come a long way since we worked on them at HMCTS. From what I can see they work absolutely fine in the GOV design system :).

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

[Astra-Gal]

@trevorsaint Thanks so much for the swift reply! I'm new to the GOV design system, and was trying to understand how the tabs worked 'under the hood'

[lfdebrux]

Hi @Astra-Gal, the current recommended implementation of the tabs component in the GOV.UK Design System is in GOV.UK Frontend here: https://github.com/alphagov/govuk-frontend/tree/main/src/govuk/components/tabs. I hope this helps!

[Astra-Gal]

@lfdebrux that's very helpful - thanks very much!

[eserkansozer]

Hi! How can I possibly default select the second or the third tab? It seems when I set "govuk-tabslist-item--selected" and "govuk-tabspanel--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 https://github.com/alphagov/govuk-frontend/issues/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.)