govuk-frontend
govuk-frontend copied to clipboard
alphagov
For discussion: Make the labels for checkboxes and radios full-width
I noticed recently, when filling out one of the various covid-related services on my phone (in a hurry, and slightly distracted) that I instinctively went to tap the whitespace to the right one of the labels for a checkbox, which didn't work.
A recent change to the GOV.UK homepage made the tap touch targets there larger (including whitespace and the text below a link).
The accordion component also allows you to the tap the whitespace to the right of the label, as does the regular labels for text inputs.
Should we do the same for radio and checkbox labels? The benefit would be especially felt where the label is very short (eg "Wales" in a list of countries.
One possible reason not to do it might be that some users may select the option accidentally, and not realise. However this risk may be small as the checkbox and radios themselves are quite large, and mobile devices are fairly good at distinguishing between scroll gestures and tap gestures. It's a consideration though.
The NHS Design System already does this for their checkbox labels (although curiously not for their radio labels).
Worth noting that this was a conscious change originally made in https://github.com/alphagov/govuk-frontend/pull/634, which also aligned it with the behaviour from GOV.UK Elements, so this would effectively be reverting that.
There's more context on the thinking at the time in that PR and associated issue.
@36degrees ha, interesting, thanks! We wondered (on the cross-gov Design Systems chat) whether there was any history behind this, or the NHS version... 🤔
As a suggestion, what if we only reactivated the full width on smaller screen sizes? It feels like at smaller sizes it would have the most benefit and at larger sizes create the most risk with the likelihood of larger space and the difference in interaction with a mouse vs fingers.
As a suggestion, what if we only reactivated the full width on smaller screen sizes? It feels like at smaller sizes it would have the most benefit and at larger sizes create the most risk with the likelihood of larger space and the difference in interaction with a mouse vs fingers.
@owenatgov interesting idea. I worry slightly that the inconsistency between mobile and desktop might be confusing (and what about tablets)?
The risk of mis-clicking could possibly be mitigated by recommending that checkboxes and radios should usually appear in columns no wider than a 2/3rds grid column? Alternatively we could look at applying a subtle hover state, like the accordion and the gov.uk homepage uses, which might help make the bigger click area more discoverable too.
It's hard to evaluate how big the risk of mis-clicking (and the user not noticing) is though. The NHS design system still has full width labels for checkboxes (but not radios) - we could reach out to them to see if it's ever come up in research?
The NHS design system still has full width labels for checkboxes (but not radios) - we could reach out to them to see if it's ever come up in research?
From looking at their code, I am pretty confident that this is unintentional and based entirely on the order that components are imported and defined in the CSS.
In both GOV.UK Frontend and NHS Frontend, the label elements for checkboxes and radios have both the __label modifier class for the component and the label class.
The __label modifier class has display: inline-block:
https://github.com/alphagov/govuk-frontend/blob/3f264256fa01c8d5b5d4e8121756e50d866eda7d/src/govuk/components/checkboxes/_index.scss#L66-L73
The label class has display: block:
https://github.com/alphagov/govuk-frontend/blob/3f264256fa01c8d5b5d4e8121756e50d866eda7d/src/govuk/components/label/_index.scss#L2-L9
Both classes have the same specificity, and so whichever appears in the CSS last 'wins'.
Components in GOV.UK Frontend that rely on other components import them at the top of the file. For example, the checkboxes component relies on the label component, and so imports it:
https://github.com/alphagov/govuk-frontend/blob/3f264256fa01c8d5b5d4e8121756e50d866eda7d/src/govuk/components/checkboxes/_index.scss#L1-L6
This means that the CSS for labels will appear before the CSS for checkboxes and radios in GOV.UK Frontend.
For whatever reason, NHS Frontend doesn't do this. Therefore the components appear in the CSS in the order they're imported, which is alphabetical.
This means the label component comes after the checkboxes, overriding the display property, but radios comes after label and so radios still get display: inline-block as intended.
I did a quick review of other design systems (that I know of) and there's a fairly even mix of behaviours:
Full-width labels:
- US government
- Transport for West Midlands
- Atlassian
- National Institute for Health and Care Excellence
Variable-width labels:
Other designs
- ONS checkboxes – they have a fixed width label with a border surrounding the label and the checkbox.
The labels are distinct from the other examples given in that they are 'open'. They are visually presented as plain text, with no keylines, borders or hover states indicating that there is an activation area or interaction that will take place—unlike GOV.UK's homepage cards, accordion's headers, or our own compact checkboxes.
Previous research has found that users don't tend to grok that labels are clickable in the first place, so I don't think there is value in amending the visuals or adding a hover state to make this interaction clearer either.
I'm struggling to see any value in making the labels full-width, as experienced users are more liable to click the label text than the empty space next to it, and having whitespace perform a function of any sort when clicked feels both unexpected and unintentional.
@querkmachine good points! I'm also not sure whether this is a good idea or not. As I see it, the main benefit would be having a bigger click area, particularly for short labels, which may aid some users with mobility impairments, and be a marginal speed improvement for everyone else (eg when using a mobile phone one handed). This would have to be to weighed against the possible downside of unexpected behaviour or unintentional clicks. Both are pretty hard to quantify!
The question of whether an active area ought to have a visible or at least implied border is an interesting one! I don't know the answer to that.
Interestingly, the ONS Design system checkboxes uses a fixed-width for the labels to increase the click area, but also renders a border around both the checkbox and the label:
Thanks to @36degrees, the NHS Design system has recently switched to making the labels non-full-width (which was unintentional), although the change doesn't seem to have hit their checkbox guidance page yet.
If we have a consensus to avoid making any changes just yet, I'd be happy to close this pull request, and we can reference this debate on the Checkbox backlog issue thread instead, in case it comes up in future?
Hi @frankieroberto,
We discussed this again earlier today and have decided that we're going to close this PR without merging.
We would want more research into how this change would affect the usability of these components before making this change. I've tried looking at some of the design systems you linked earlier to see if there was any prior user research supporting the change, but couldn't find any on a quick glance.
I've opened an issue to that effect: #3072, though this is admittedly unlikely to be tackled in the near term.
Thanks for your contribution regardless, and the discussions (and NHS DS bugfix!) that it spawned.
@querkmachine thanks. I wasn’t sure if this was necessarily a good idea, but the discussion has been interesting (and helped the NHS Design System!).