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.

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

[enoranidi]

We are currently using the different tag colours in our internal service for the different status messages for users to understand. However when we did some accessibility testing with someone who had dyslexia (who was also using a yellow filter on their screen) they mentioned that the text colours were not bright enough and the contrast was not sufficient.

I looked at changing every single tag colour to use the default black text colour (#0b0c0c) and crossed checked against an accessibility colour contrast checker here: https://colourcontrast.cc/

The results (from using the colour contrast checker) were positive and met AA and AAA WCAG standards so we are now going to implement this change into our service but continue to test and check we are still meeting the accessibility needs of our users.

[tomshawdwp]

Hi, has anyone experimented with making tags expandable? We have a use case where in most cases a tag's worth of content can describe the situation, however it might be useful to be able to open it up and see a more descriptive paragraph if needed. Is this the right element for something like this? Happy to hear thoughts. Cheers

[adyhoran1]

My service has created a custom CSS class for an amber coloured tag:

<style> .dfe-tag--amber { color: #66420d; background: #ffe4bc; } </style>

The purpose of this is for displaying red-amber-green risk rating categories.

We use govuk-tag-green for green ratings and govuk-tag-red for red ones. However, we felt govuk-tag--orange and govuk-tag--yellow would not work well for the colour amber (here's an example of using govuk-tag--yellow for the colour amber)

We believe the colour contrast of this amber tag is accessible. We have also tested the tag in user research sessions with our core user group, and they have reacted well to it.

Please let me know if you have any questions 🙂

[querkmachine]

I've done some experimenting with alternative CSS implementations for tags, with the aim to resolve the full-width box appearance that is introduced when tags wrap over multiple lines.

https://codepen.io/querkmachine/pen/VYZBjaq

[jeana-adhoc]

I'm curious if you all consider these tags needing to meet 1.4.11 (Meaning - needing the color background to meet 3:1 contrast ratio with the page background)? And if not, is that because it's not an interactive control? I know you're not using color alone to convey meaning. I'm just trying to understand if we need similar status tags to meet 1.4.11 in our use case.

[james-roberts-cgi]

The colour difference between green and red is very small for colour-blind people. (me anyway).
Obviously, there is the text as well - but its confusing enough for me to want all of them to be grey.

In https://design-system.service.gov.uk/styles/colour/ the red/green for error/success is almost indistinguishable.
But red and light-green are more easily distinguishable (if we are absolutely hell-bent on using commonly confused colours for polar opposites in meaning).

[CharlotteDowns]

In version 6.0 of GOV.UK Frontend we updated the colours of the tag component to align with the updated GOV.UK colour palette. The new palette is updated on the GOV.UK Design System website (styles > colour)

[manalishi79]

Can I ask why are tags set to a CSS property of max-width:160px

Seems arbitrary

[owenatgov]

@manalishi79 It's calculated here: https://github.com/alphagov/govuk-frontend/blob/879c0236882433f571f284554eba63dd4b662f97/packages/govuk-frontend/src/govuk/components/tag/_index.scss#L39

It's half the default width of the minimum screen width, which defaults to 320px, therefore 160px.

This is here because we need a max width so that word breaking will work on tags, as per this PR: alphagov/govuk-frontend#4259. More details in this issue: alphagov/govuk-frontend#3923. The half of mobile value came from a rough average of 30 characters ased on discussions around typical length of a tag in the task list component, so sort of arbitrary in that we had to pick something but not arbitrary in that we did think about it.

If this is causing problems you can override it fairly easy, although bear in mind removing it will reintroduce the issue dscribed in the issue re: long tags. Is the setting causing you problems?

[cisasearching]

Hello,
User research I have seen has seen users confusion between "Complete" "Incomplete" and "Completed" statuses - because of the similarity of the words. Sometimes we just used "Complete" and "Completed" sometimes we used "Incomplete" and "Complete" and sometimes a mix of the three.
In other rounds, projects - we tested "To do" and "Done" and also "Not started" with "Done" both of which performed better.
Has anyone else found this?

[steve-oconnor]

@cisasearching That's interesting to know and makes sense. What type of users of they?

The words used on the component listing were only ever supposed to be suggestions, with guidance to use what works for your service. I'm not sure what happened to that.