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

Tabs #100

Open
govuk-design-system opened this issue Jan 15, 2018 · 50 comments
Open

Tabs #100

govuk-design-system opened this issue Jan 15, 2018 · 50 comments

Comments

@timpaul
Copy link
Contributor

@timpaul timpaul commented Apr 16, 2018

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

@ignaciaorellana ignaciaorellana moved this from Agreed to In progress in GOV.UK Design System Community Backlog Apr 18, 2018
@timpaul
Copy link
Contributor

@timpaul timpaul commented May 2, 2018

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

@penx penx mentioned this issue May 2, 2018
6 of 12 tasks complete
@timpaul
Copy link
Contributor

@timpaul timpaul commented May 4, 2018

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:

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:

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
Copy link
Member

@joelanman joelanman commented May 8, 2018

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
Copy link
Contributor

@timpaul timpaul commented May 8, 2018

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

@adamsilver
Copy link

@adamsilver adamsilver commented May 8, 2018

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

@joelanman
Copy link
Member

@joelanman joelanman commented May 8, 2018

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 timpaul changed the title Tabs Tabbed panel May 9, 2018
@timpaul
Copy link
Contributor

@timpaul timpaul commented May 9, 2018

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
@adamsilver
Copy link

@adamsilver adamsilver commented May 11, 2018

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
Copy link

@adamsilver adamsilver commented May 11, 2018

These DWP internal services use tabbed panels with JS:

  • Manage Bereavement Support Payment
  • Access to Work Integrated System
@abbott567
Copy link

@abbott567 abbott567 commented May 11, 2018

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 adamsilver commented May 14, 2018

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

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

@adamsilver
Copy link

@adamsilver adamsilver commented May 17, 2018

Judicial case manager screenshots

With a cheeky example of sub nav too.

Big screens

image

Small screens

jui-prototype herokuapp com_app_case_bv18d00150_parties nexus 5x

@adamsilver
Copy link

@adamsilver adamsilver commented May 17, 2018

Court Case Data Screenshots

Big screen

image

Small screen

image

@adamsilver
Copy link

@adamsilver adamsilver commented May 17, 2018

Bank holiday screenshots

Big screen

image

Small screen

image

@adamsilver
Copy link

@adamsilver adamsilver commented May 17, 2018

Find a charity uses tabbed panels

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

Big screens

image

Small screens (broken)

image

@adamsilver
Copy link

@adamsilver adamsilver commented May 17, 2018

Find and compare schools screenshots

Big screens

image

Small screens (broken)

image

@timpaul timpaul removed the candidate label May 18, 2018
@joelanman
Copy link
Member

@joelanman joelanman commented Aug 8, 2018

@fofr Not that this is a blocking comment to your suggestion, but just for context: I think originally it was to convey that these are not normally functioning links (they don't take you to another place on the page, or to another page) but instead act as tabs. I think this is probably up for discussion though. The link style certainly has clear affordance.

@abbott567
Copy link

@abbott567 abbott567 commented Aug 18, 2018

Just realised there is no hover state on any of the tabs. Will this not compound the problem with it looking like body text? Also, is it accessible to not have a hover state at all?

aug-18-2018 09-25-16

@adamsilver
Copy link

@adamsilver adamsilver commented Aug 18, 2018

Given the thread so far, I suggest the next, simplest iteration would be:

  • make the grey background darker to meet accessibility guidelines
  • add a hover state (beyond just the cursor change)

image

Then, if that's not enough, we could change the colour:

image

Then, if that's not enough, we could look at:

  • borders
  • underlines (which I'm not keen on as per Joe's explanation above)
@ignaciaorellana
Copy link
Contributor

@ignaciaorellana ignaciaorellana commented Sep 4, 2018

Hi,
I hope this is the right place - I had promised to include the BBC tabs in out next user testing. Had a test with a relatively unskilled long-time blind (or nearly blind) iPhone user which I have uploaded here on Youtube:
https://www.youtube.com/watch?v=6lVLHGOsylU
I hope you can work out what happens without me translating the German captions...

This was original posted by @detlevhfischer in alphagov/govuk-design-system#526

@36degrees
Copy link
Member

@36degrees 36degrees commented Sep 5, 2018

For context, I believe @detlevhfischer's comment is related to this issue – alphagov/govuk_frontend_toolkit#464 (comment)

Thanks!

@timpaul
Copy link
Contributor

@timpaul timpaul commented Sep 24, 2018

Here's a version of the same video with English language narration: https://accessuse.eu/en/tabbed-interfaces.html#govuk

@detlevhfischer
Copy link

@detlevhfischer detlevhfischer commented Sep 24, 2018

@timpaul The video on https://accessuse.eu/en/tabbed-interfaces.html#govuk is actually not the same as the one I uploaded to youtube. It is an earlier stage (the user had not yet been told that he has to activate the tabs to open the respective panel, and develops his own strange mental model --- by counting). The video on YouTube https://www.youtube.com/watch?v=6lVLHGOsylU shows another sequence with the same user that followed after that.

@amyhupe
Copy link
Contributor

@amyhupe amyhupe commented Oct 15, 2018

Dropbox Paper audit

On 15 October 2018 the Design System team reviewed a Dropbox Paper document discussing the Tabs component.

The aim was to reduce the number of places containing guidance and code by:

  • migrating relevant, useful content into the Design System itself
  • recording important research findings in the community backlog
  • removing the original Dropbox Paper page

Below is a record of the outcomes of that review.

If you need to, you can see the original Dropbox Paper content in the internet archive.

Review outcomes

Updates to the Design System

The Design System team will carry out the following updates to ensure that relevant, useful content from the Dropbox Paper file is added to the Design System.

  • Add guidance to the Design System saying how the tabs component works when JavaScript is not available.
@abbott567
Copy link

@abbott567 abbott567 commented Feb 6, 2019

Hi, does anybody know what's happening about the colour contrast on the tabs component? It was initially called out in June of last year, and it's still causing us issues 8 months later. We're still maintaining a DWP version of the tabs component with a WCAG-AA compliant contrast just so it shows up on Government equipment. It would be good to get some sort of indicator on the progress of this as it continues to be a pain to manage. Thanks.

@dashouse
Copy link

@dashouse dashouse commented Feb 6, 2019

@abbott567 We're doing a large piece of work at the moment to meet WCAG 2.1 AA (so our users can by 23rd September 2019) - You can see what we're looking at here alphagov/govuk-design-system#677

There's lots wrapped up in this from a colour contrast / broader colour palette perspective frontend wide but tabs will be a part of it.

@abbott567
Copy link

@abbott567 abbott567 commented Feb 6, 2019

Cool, thanks @dashouse 🙌

@dizzyack
Copy link

@dizzyack dizzyack commented Apr 26, 2019

Trying to link from Tab1 to an anchor point on Tab2 but cant get it working, i can get the link to open Tab2 but not then scroll down to the anchor point i want, has anyone come across this before?

@dashouse
Copy link

@dashouse dashouse commented Apr 29, 2019

@dizzyack Because the tabs use id's in the URL themselves, for example #tab-1, #tab-2 you won't be able to deep link from one tab to a particular part of another tab. The tab will always reset itself to the top of the screen so the user is made aware that the tab has changed and they are in a different section.

@andymantell
Copy link

@andymantell andymantell commented Oct 14, 2019

The notes at the bottom of the page on the design system say:

User research is needed to confirm:
that this approach to tabs is the best option for screen reader users and sighted keyboard users

Has anyone since observed these being used by the above type of user? There are those around the internet that claim the Aria tablist pattern is not a good one on the basis that users aren't aware they can use the arrow keys, and instead expect to be able to tab through them in the normal manner. It's always that tricky balance of complying with a recommendation from something like the Aria spec, vs what people are familiar with. For reference, see:

https://simplyaccessible.com/article/danger-aria-tabs/

There's plenty of material recommending the Aria/Arrow key approach, but most of them take the form of instructional articles on how to comply with the Aria spec, not backed up by any research.

Has anyone observed anything in any of their testing? We have not yet gone out to test this specifically - it got raised here by a tester who was unaware that the arrow keys could be used and was unable to use their keyboard to active the tabs (In effect, a very tiny bit of user research in itself! )

@nickcolley
Copy link
Contributor

@nickcolley nickcolley commented Oct 14, 2019

We have a related link to that article in the original list of links for this backlog entry above.

Around the time that article was published Léonie Watson and some other accessibility folks published this:

I would welcome any more real user testing as always but just sharing this as it's relevant for the conversation.

@andymantell
Copy link

@andymantell andymantell commented Oct 14, 2019

ok thanks Nick, that is a pretty strong rebuttal - I'll pass the information on. Obviously research is key, but there's enough there that I can help the team to feel comfortable with rejecting the issue that was raised.

@simon-westcott
Copy link

@simon-westcott simon-westcott commented Nov 20, 2019

Tabs have been used and tested successfully on Help to Save. Currently in public Beta.

@timpaul
Copy link
Contributor

@timpaul timpaul commented Sep 14, 2020

Just an update on the previous conversation above about the contrast of unselected tabs.

We added underlines to the text, so users would understand that unselected tabs were clickable, even if they couldn't see the tab boundaries.

We believe that this meets the relevant success criterion of WCAG 2.1 (Non-text contrast) - but please let us know if you see it causing issues in user research.

image

@armstrongb
Copy link

@armstrongb armstrongb commented Sep 15, 2020

@timpaul we've had the underlines on the tabs with a grey background in our component library for quite some time now and haven't had any reported issues in use.

@hopebristow
Copy link

@hopebristow hopebristow commented Apr 27, 2021

We have used this pattern within check and pay for multiple vehicles as part of the Drive in a Clean Air Zone (https://www.gov.uk/clean-air-zones) service. Tabs allowed us to separate a grid which allows a user to select payment dates for multiple vehicles across 13 available payment dates. We found tabs to be the only successful way to display the many dates available for a user to select to pay for multiple vehicles. Other designs such as showing both grids on one screen caused confusing for users as there was too much information. Through usability testing, 122/136 users tested the tabs design and were able to use them independently and complete the task of selecting and paying for the vehicles and days.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet