Provide a disabled style for radios and checkboxes

[timpaul]

An interesting comment on our recent blog post asked if we'd created disabled styles for the new custom controls. I'm pretty sure we haven't. Whilst it's true that we want to discourage use of disabled form controls I wonder if we should at least have an appropriate style if they are used?

[edwardhorsford]

We probably should. I thought about this last week and then promptly forgot about it.

[edwardhorsford]

Half an idea. Would want to test heavily - I'm not at all sure it's clear.

Radio isn't contrast safe, but the text is.

[cjforms]

Hi all - hello! I'm back.

What's the user need?

It's possible - indeed, frequent - that there's an answer in the user's mind that isn't available in the official list of options. I've seen this implemented in two ways:

1. By not offering the answer
2. By offering the answer, and then implementing logic to explain why the answer isn't going to work for the service and to guide the user to an answer that's acceptable for the service.

Method 1 is easy but unhelpful for the user.
Method 2 counts as 'do the hard work to make it simple'.

What I've never yet seen is a disabled option. Not to say it's not out there somewhere on the Internet, but it's not in my extensive library of examples.

[edwardhorsford]

Hi @cjforms,

We don't want to offer this - I'd expect our guidance would still remain "don't do it".

With that said, it's an attribute that can be set on checkboxes and radios - we can't stop services using it. Right now if a checkbox or radio has the attribute set, they will be unclickable, but not otherwise visually different - this would look buggy and be really confusing to users.

Thankfully disabled radios and checkboxes are rare - great you've not seen one! There's an example here (click the button to disable it)

---

Agreed on both of your alternate suggestions. If we write some guidance in the service manual on checkboxes and radios, I'd like to say something similar about alternatives to disabling fields.

[cjforms]

Thanks for the explanation - and pleased to see that the example is a demonstrator, not something that's live.

Speculation: could the 'disabled' appearance change the thing from a target to the words 'don't do this'?

[joelanman]

I was just trying to think of actual user needs for disabled inputs. What about the situation of a faceted search - say you're searching for government documents, and your search means that no 'Secret' documents are found. Might that be a reason to disable - or would it be better to remove the option (could be confusing, where did it go?) or just allow it.

[joelanman]

for reference, I think this is how the old styles looked when disabled:

[NickColley]

I've also seen people use cursor: not-allowed for users using a mouse, not sure if this would help users understand something can't be clicked.

https://developer.mozilla.org/en/docs/Web/CSS/cursor

[timpaul]

For the search filter example you could have the number of results in brackets after the label, so 'Secret (0)' in your example. Hopefully then you wouldn't need to disable it.

The one time I think disabled form controls might be justified is for high frequency, information dense admin interfaces - where the UI has a dashboard feel. In that instance it might be preferable to disable controls rather than have things randomly disappearing.

[joelanman]

@timpaul that's true, but the number might not actually be useful apart from when it's showing 0

I feel like we can't be 100% that no-one out there has a user need for disabling inputs, so we should just fix that bug for now by using a grey style, even if it doesn't pass contrast tests. At the same time present the same strong recommendation against them as we have for disabled buttons.

http://govuk-elements.herokuapp.com/buttons/#button-disabled

[cjforms]

@timpaul good point. I don't have many of those in my screenshot library.

+1 to what @joelanman said

[selfthinker]

Not encouraging it is one point. Then we should not include an example in the style guide, or maybe even include a comment about it.
But making disabled options look essentially broken by default is another point. I'm generally for including all possible default styles. Because we cannot control if developers use them or not, and when they do, it shouldn't look broken.

[robinwhittleton]

Happy to implement. Could a designer come up with a style for me to build?

[edwardhorsford]

I suggest setting opacity (or similar) at 50%. It still passes contrast checks (4.76:1) and is somewhat visually different.

Without doing research we don't know if this is clear or not, but it's better than it being styled exactly the same.

[edwardhorsford]

I was going to suggest a slight fill to the background of the circle, but I could see that might cause issues if the checkboxes were used on alternate colour backgrounds or inversed. I'm not sure it's worth doing.

[fofr]

Would the strikethrough styles be useful on the text? Means the text takes a legibility hit.

[fofr]

On second thoughts, strikethrough would suggest an option isn't available, rather than the option can't be changed. eg A previously selected value that's correct but now disabled.

[fofr]

@edwardhorsford In your screenshot there's a weird behaviour. A single radio option is selected but disabled. If you built the HTML for that and clicked one of the other options you could still change the value for that part of the form: https://jsbin.com/hodulifojo/edit?html,output

[edwardhorsford]

@fofr I just picked it as a random example - but I assume it's still a potential use case. I'd expect the more normal case is that it's disabled and un-selected.

[fofr]

For the normal disabled case, where all radios are disabled you could:

• Hide the options that are not selected and can't be selected
• Hide the interactive part of the selected radio
• Display the label for the selected radio as text

In the above example you would see:

Where do you live?
Isle of Man or the Channel Islands

[timpaul]

I feel like the above example should be dealt with by different markup rather than by restyling form controls. For now, can we go with a greyed out control and label that passes contrast? No additional design elements, no mousover effects. I'm guessing the $secondary-text colour works?

[edwardhorsford]

@timpaul I think that relies on secondary text colour always looking light grey. What if we change it in the future?

I went with 50% contrast for these reasons:

• Nearly identical to $secondary-text-colour
• Passes contrast
• Matches our 50% rule for disabled buttons
• Doesn't tie us to a secondary colour. It's always tied to the main colour. If we one day change secondary text colour to a different colour (or black), we'd have to adjust this.

[edwardhorsford]

Both colours are so similar, it doesn't matter much anyway right now. The main thing is it looks a bit different than the normal state.

[trevorsaint]

@edwardhorsford has this styling been pushed into master? Or likely to be? This would be something very useful for us @ministryofjustice. If its available via GOV Elements I won't need to add this.

[robinwhittleton]

I started trying to build this last week but ran into a problem. We rely on the selection buttons JS in frontend toolkit to set state classes based on events the real input emits. Unfortunately there’s no disabled event that gets emitted. To track that there’s a class of mutation events you can hook into, but they’re an absolute minefield of browser compatibility.

In a closed-loop system you’d instead hook onto the element that triggers the setting of disabled against the radio button, or have some sort of pubsub system (or something like React) that knows how to update based on system state. We can’t guarantee either of those for elements.

A probable best solution in a medium-term future is to bite the bullet and reorganise the markup of the radio buttons and checkboxes. For example:

<div class="custom-input">
  <input type="radio" id="my_radio" />
  <label for="my_radio">My radio button</label>
</div>

would allow us to drop the JS completely and use CSS:

input + label::before { …code for ring… }
input:focus + label::before { …code for focus ring… }
input:checked + label::after { …code for bullet… }
input:disabled + label { opacity: 0.5; }

Obviously this would need to be tested properly (for browser compatibility and accessibility, but it’s probably a better solution. IE8 and lower don’t support the pseudoclass states on inputs, but they also don’t support pseudoelements against the labels so we can just fall back to native inputs (live we do at the moment).

[moj]

You perhaps meant @ministryofjustice and not @moj

[robinwhittleton]

I’ve pushed a branch with code to remove the JS requirement and implement a disabled state. This is by no means ready for production and may not make it into Elements at all, might land in GOV.UK Frontend. Still, if you want to see what it would look like…

[taylorsj1980]

Hi all,

Do you know when this might be released into the live code? We're about to go live with the latest version of Gov elements and have one area where we disable a button.

[robinwhittleton]

I don’t have any plans to add it to Elements, but I’ll canvas opinion on the x-gov Slack and see what people think of the idea.

[edwardhorsford]

@taylorsj1980 could you share a screenshot / example of your use case? Note also this is about disabled radios and checkboxes, not disabled buttons.

[taylorsj1980]

@edwardhorsford @robinwhittleton Thanks for the response.

Apologies - I did mean radio buttons in our case. Not just buttons.

Biggs Thorarensen has add some details of our situation with LPA in Slack so I'll join the conversation there.

[adamsilver]

As others have already said it's rare that disabling form controls is a good experience.

With that said, here's another situation where we might need it:

The user can select up to 3 options out of say 10 (presented as checkboxes). With Javascript you can enhance the interface to disable the remaining 7 once 3 have been selected. I am far from certain this is a good experience but throwing it into the mix anyway.

I also think it's not particularly reasonable to expect people to adopt a custom checkbox and radio button implementation where native attributes such as disabled are not reflected.

[gemmaleigh]

GOV.UK elements was missing examples of disabled radio buttons and checkboxes, these were added in #519.

Fixed by #519.