Tag

[govuk-design-system]

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

[abbott567]

We have these in our service to show the status of a claim. However, we have modified the background colour so agents can quickly identify allowed claims vs disallowed claims etc. Is there any scope to add modifier classes for this?

eg: .govuk-c-tag .govuk-c-tag--danger

[NickColley]

@abbott567 makes sense! For now when you're extending the classes make sure to change the namespace to something that will not conflict in the future: .app-tag--danger etc

[mrkwrght]

we have modified our status tags on the tasklist to be easy to read by mading them lower case and upping the font size to 19px like the rest of the text.

we have also created a 'In Progress' tag because it wasn't clear to our users which tasks had been started when navigating back to the tasklist.

feedback would be great!

[jennifer-hodgson]

Interested to know findings about use of coloured status tags as opposed to simple text (as per the GOV.UK Design System community backlog), following discussions in the HMRC design community.

[dashouse]

Tags spotted on MOT History service

[adamsilver]

On the Apply for teacher training services at DfE we use the Tag component extensively.

But the colours were found to have poor contrast in our recent accessibility DAC audit.

We've solved this by using tints...

Original styles with poor contrast

Here's a few screens with the original design:

Task list with outlinedd incomplete tag

State of individual course choice

Other states from the provider point of view

Proposed design with good contrast

Here I've used tints of the GOV.UK Design System colour palette.

Task list

State of individual course choice

Other states from the provider point of view

[timpaul]

Working group review: additional colour variants

On 13 February 2020 the Design System working group approved the addition of different coloured variants of this component. Here’s a summary of recommendations that working group members made, and of our decisions regarding them.

---

Recommendation: Use white text on a standard colour background

Decision: No action. There aren’t enough colours from the standard palette that contrast sufficiently against white to provide enough options. Also, the MOJ has found that some users confuse tags with white text on a coloured background for buttons.

---

Recommendation: Use standard coloured text on white background, with a border in the same colour.

Decision: No action. As above, there aren’t enough colours from the standard palette that contrast sufficiently against white to provide enough options.

---

Recommendation: Reduce the number of colours provided.

Decision: No action. There is evidence that some services that need this many colours, and the guidance recommends using ‘as few as possible’.

---

Recommendation: Increase the tonal contrast between different tints.

Decision: No action. This wouldn’t be possible with this many colours. The guidance points out that colour should only be used as an enhancement, so designers should not rely on users being able to perceive the difference.

---

Recommendation: State which colours to use for specific status types.

Decision: No action for now. If we did this it would need to be at the system level rather than just in this component. Colours don't have a consistent meaning across different cultures, so defining the way they should be used would need to be done with care. The existing examples probably do this with a light enough touch.

---

Recommendation: Change the name of the component to ‘phase’ or ‘status’

Decision: We will add these as aliases to the search, so that people will find the component if they use those terms.

---

Thanks as always to everyone who gave their time to this. We will publish the updated component in the next 2 weeks.

[edwardhorsford]

I'd like to suggest that the css for the tags includes nowrap of some kind. If tags contain longer bits of text or happen to hit the breakpoint poorly, they wrap, looking weird.

I can't think of a scenario where you would want it to wrap.

Example from another team that was shared on Slack:

[joelanman]

I think in a case like this from previous in the thread you would want it to wrap rather than break the column

[frankieroberto]

The NHS Digital team used the Tag component within an accordion on the Get a coronavirus test service to indicate the availability of tests within different regions.

They found that it was very common for users to click the green 'AVAILABLE' tags, thinking that this would let them book an appointment.

[cjforms]

"If something looks like a button, users will treat it as a button" (by me, constantly)

It's a corollary of "Basic Best Practice for Buttons number 1: Make the Buttons Look Like Buttons"https://www.uxmatters.com/mt/archives/2012/05/7-basic-best-practices-for-buttons.php

The obvious solution is: make them into buttons. Then everyone is happy.

[kelliedesigner]

Agree @cjforms

Building on Tag to include the ability to make it a link is something @fofr has been exploring at MOJ in an internal product for probation practitioners to manage supervisions with people on probation.

Design history post: https://ms-design-history.herokuapp.com/risk-tab/

This could be something we contribute to the GOV.UK Design System

[frankieroberto]

This is something we are exploring as part of the Task List collaboration.

[edwardhorsford]

Like the NHS I've seen multiple participants test if they can click on them - though the number who click are still in the minority - I might estimate 20-30% of participants. However they don't expect they are or should be clickable - it's more that they're unsure. When presented with the interface they wonder aloud whether they are clickable, and test that behaviour.

I've yet to come across a participant where this has been a blocker - after they realise they're not clickable, they're fine.

This raises the question of whether the benefits of the the tag being visually distinct outweighs the downsides that some users attempt to click them.

---

I'd be wary of making these in to buttons. Tags show 'the status of something' - they don't always logically do or go anywhere.

Example from my service:
A list of records with statuses - the tag could be a button.

When you open a record, the same status is shown - here a button would not make any sense.

Making it a button would raise several questions:

• Do they sometimes then act as buttons but sometimes not?
• If they do act on buttons, do we get rid of links / other buttons as well that we were originally using? or have two UI components going to the same destination? (a minor accessibility issue)
• How do you show the status of something (the purpose of the component) when you don't want a button.

[cjforms]

Excellent points as always @edwardhorsford

I've only seen them in the context of task lists, and I agree that a sometimes button / sometimes not button tag wouldn't be a good idea.

My response to your questions might be:

• Do they sometimes then act as buttons but sometimes not?

No, that would be a nightmare

• If they do act on buttons, do we get rid of links / other buttons as well that we were originally using? or have two UI components going to the same destination? (a minor accessibility issue)

I've seen plenty of instances where buttons have variations for assorted reasons. These do not seem to disconcert users at all, so long as the buttons look sufficiently 'buttony'.

• How do you show the status of something (the purpose of the component) when you don't want a button.

With formatted text that does not use buttony formatting? (now you'll correctly challenge me about what that might be - I think the buttony effect comes from having a rectangle of colour behind the text. But this is the one where I feel that I'm on the shakiest ground - thanks for asking it.

[emilycolmanDWP]

I'm interested to know whether status tags were always intended to be automated, because they're essentially a result of something that's occurred. For example, the user completes a section within a task list > status is automatically updated to 'Completed'.

We are using status tags within our internal case management system for health assessments, however the user has to manually update the status once they've finished a task because the back-end capability isn't ready to support automation yet (as I understand it). They currently do this by visiting a screen that asks them which status they want to update to, with a list of radio options to choose from. It has very much been built from a technical architect's perspective. We have tried to keep the statuses as broad as possible, but user feedback has indicated that they need additional ones, and at a more granular level. This means the radio options screen will get longer, which brings its own concerns.

We're also running into other difficulties and I won't outline them all here, it would be great to get in touch with someone who is well-versed on the use of status tags or even introduced them to the design system.

[fofr]

For reference, as @kelliedesigner mentioned, this is how we are trying out a tag that is also a link on the MOJ probation service – trying to make it more link like rather than button like.

Hover and focus states:

---

MOJ also has what it calls a badge component that only uses a coloured border, rather than a background, which might be less buttony (I don't know if people are trying to click these as frequently):
https://design-patterns.service.justice.gov.uk/components/badge/

---

At DfE on the Get help with tech service we observed users attempting to click tags – these were the majority of users in research, and they did not always recover by clicking the school link on the left. This was the layout causing that issue:

[Rich-Cooley]

We are using tags as part of HMRC's making tax digital work. I have an interesting situation where we need to show tags with an appropriate status and something to indicate there are one or more errors in that section.

I'm wondering if anyone has experimented with combining tags with something like a small count to indicate the number of errors? It may be something like this… 1️⃣

[dominichurst-ur]

I am working with DfT on the Create Fares Data project. (Bus operators submitting information). One screen is your typical table with a tag status. The table can get quite long depending on how many services you have and we want to include messaging/ alert to the top of the page if a service has a certain status/ tag. (eg "Needs attention"). The question is does anyone do something similar and if so how. I was thinking inset text or warning text

[CharlotteDowns]

@dominichurst-ur it might be also worth looking into the notification banner component.

[dombillington]

Is there a reason why the text in the tag element is in uppercase? We're trying to avoid uppercase content to help with readability so it would be good to know if there's a clear justification for the uppercase text in this element.

[MMDWP]

Is there any chance we can increase the contrast radio abit for some of the text colours within tags?
In UR we had couple people say they struggle with the Red in particular.

I've had a check of the and its coming out as AAA for 'large' and AA for 'Regular' (See screen shot, granted its just the first contact radio checker found)

AAA for the large text, but at 14pt, I would say its really 'normal', just bold and with wider kerning
When tested against 'regualar' weight type its only AA.

The blue is also only AA at 'normal'

[36degrees]

In GOV.UK Frontend v5.0 (released 8 December 2023) we changed the design of the Tag component to improve accessibility and readability.

Text within the tag is no longer bold and uppercase with extra letter spacing. It's now regular 19px text with the first letter of a word capitalised and the rest of the content lowercase. Due to this, there might be changes to the width of existing tags.

The colours have also changed to make them more distinguishable from buttons.

Before

After

These changes were introduced in:

• Tag design changes govuk-frontend#3502
• Remove the first letter modifier from the tag component govuk-frontend#3731

[36degrees]

Is there any chance we can increase the contrast radio abit for some of the text colours within tags? In UR we had couple people say they struggle with the Red in particular.

@MMDWP as mentioned above, some of the tag colours changed in v5, including red which is now #2a0b06 on #f4cdc6. This provides a greater contrast ratio of 12.52:1, which now passes WCAG 2.2 1.4.6 Contrast (Enhanced) (AAA) for normal text.

I've also checked blue tags which you mentioned, which are now #0C2D4A on #BBD4EA with a contrast ratio of 9.2:1 (up from 6.52:1) and also pass WCAG 2.2 1.4.6 Contrast (Enhanced) (AAA) for normal text.

I've only given the other tag colours a cursory check, but it looks like they all meet the 7:1 ratio required for WCAG 2.2 1.4.6 Contrast (Enhanced) (AAA) apart from green which falls slightly short (6.16:1).

If you need to see the old styles for comparison they're available at https://v4--govuk-design-system-preview.netlify.app/components/tag/.

[nick-wall]

We've used tags for a summary panel in our service to check a teacher's record.

They summarise key indicators that are used in hiring decision making. They relate to other content that's elsewhere on the page.

We wanted to test if they confuse users or are needed. They tested well - most users did not particularly notice them on the page. Those that did, found them helpful and liked the clear indicators and colour to compliment the content. Some users screenshot this section to keep as a record of a check they've done. They particularly liked the status showing the absence of something that otherwise wouldn't show on the record - mainly to confirm a teacher does not have restrictions against them.

One thing we found after the update to GOV.UK Frontend v5.0 was that we were restricted in the content we could use. This was because the font size increased and we're using the one-thirds column, so some of the tags wrapped and became coloured boxes instead.

In production, we've overridden the width classes so they can be longer. For example, 'induction exempt' is now 'exempt from induction' and stays on one line. But we wouldn't be able to get much more in. Good for being concise but could be limiting if used in a confined container.

[steve-oconnor]

@nick-wall This is an example of where the guidance on tags can be adjusted to fit the usage so I would say the tags as they are in the Design System don't need any changes.

The new tag designs use the default font size of 19px as uppercase and bold were dropped so widening the column was probably the best option. That or trying to make the tag content more concise.