govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Tag
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
@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
Just a purely visual comment... The top/bottom padding on the tag is uneven and makes it look a bit wonky Can I suggest changing the top padding from 5px to 3px?
Hey Dan :)
This is because the custom font we use sits slightly higher than other common fonts, we were hoping we could release a new version of GOV.UK Frontend with vertical spacing that is more common.
In the meantime I think we could add some adjustments, I'll add a fix for this.
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!
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.
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
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.
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:
I think in a case like this from previous in the thread you would want it to wrap rather than break the column
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.
"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.
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
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.
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.
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.
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:
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️⃣
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
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.
We're using the tag component for a Police service as flags to communicate the presence of risks that come on two levels (e.g. WEAPONS and the presence of Police reports like INFORMATION). These are necessary for officers to complete an instant threat assessment and determine their actions (e.g. stop a moving vehicle, surveillance etc).
Like others here, we found that in user research, participants tend to try to click on them to get more info, but within milliseconds find the appropriate way to navigate to them. We definitely can't make them into links as some will represent more than 1 destination pages (e.g. "ACTION (2)").
In testing, participants immediately notice and successfully interpret these flags. However, many will later raise the opinion that they need to be visually more prominent (we also use small green/red panels further below the page that are visually more prominent but less urgent for users to pay attention to).
Inspired by the left thick border of the Home Office alert component, I've tried to make them more prominent and less button-y. It's not 100% conclusive but I believe we're moving in the right direction: not everyone tries to click on them and even if they do it's because they wish they were rather than they believe they are buttons. We also seem to have fewer comments about the perceived imbalance of the visual hierarchy, but influential stakeholders are pushing for a more eye-catchy tag design.
My concern is that as there can be quite a few flags concentrated on the same part of the dashboard-like overview page (and some are quite wordy), anything too prominent will end up like a Christmas tree on fire!
My questions to this group are:
- What do you think of the tag+alert hybrid design? Hubris, genius or something in between?
- Would you advise to attempt the more solid red/orange (like those shared above by @adamsilver and @abbott567)? @kelliedesigner you seem to have moved away from them in your risk tab; did they not test well?
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'
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:
- https://github.com/alphagov/govuk-frontend/pull/3502
- https://github.com/alphagov/govuk-frontend/pull/3731
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/.
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.
@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.
