Add disabled styles for form controls

[querkmachine]

Currently we rely on user agent styles to indicate the disabled state of all form controls except for radio buttons and checkboxes. For these, we reduce the opacity of both the input and associated label by 50%.

In my research, the user agent styles for disabled controls are wildly inconsistent, both between browsers and different input types. Some user agents don't visually differentiate between enabled and disabled inputs at all! For this reason, I think we should explicitly define disabled styles rather than relying on UA styles.

Whilst we don't tend to encourage the use of disabled inputs, this feels like one of those things we should accommodate within Frontend for when they are used or needed.

This change was requested in #1713. I've also added disabled parameters to our Nunjucks macros as a linked change as was requested in #1712, though this can be pulled into a separate piece if desired.

Changes

• Adds :disabled styles to the text input, textarea, select and file upload components, mirroring the 50% opacity reduction that we use for radio buttons and checkboxes. The actual CSS used for each differs slightly, as explained in this comment.
• Adds the not-allowed cursor style to disabled form controls and buttons when they are hovered over.
• Adds a disabled Nunjucks parameter to the text input, textarea, select and file upload components, with associated documentation.
• Expands the "Forms controls states" example in the Frontend review app to include more form controls and more states (and more bats).

Screenshots

Text input / textarea

Textareas look pretty much identical to these, they're just taller and have a scrollbar, so I've not screenshotted them (sorry, there's just so many!)

	Before	After
Chrome 109 (macOS)
Safari 16.0 (macOS)
Safari 16.1 (iOS)
Firefox 108 (macOS)
IE 11 (Windows 10)

Select

	Before	After
Chrome 109 (macOS)
Safari 16.0 (macOS)
Safari 16.1 (iOS)
Firefox 108 (macOS)
IE 11 (Windows 10)

File upload

	Before	After
Chrome 109 (macOS)
Safari 16.0 (macOS)
Safari 16.1 (iOS)
Firefox 108 (macOS)
IE 11 (Windows 10)

Questions and concerns

How well does this work in alternative colour modes (e.g. Windows High Contrast Mode)?

Windows HCM seems to universally apply a green border and text colour to disabled inputs, ignoring opacity-based styling entirely.

How well does this work for users with low vision?

Disabled inputs do not need to meet the 3:1 non-text contrast ratio or 4.5:1 text contrast ratio required by WCAG, but we may want to ensure a minimum level of contrast regardless.

How well does this work for sighted users?

Of particular concern to me is empty text inputs and textareas, where the lighter border colour is the only indicator that the control is disabled. This difference may not be clear if there are no other inputs to compare against.

Arguably it's unlikely that the user will be presented with a disabled input with no other options to compare it against. This doesn't mean the disabled styling is obvious, however.

Do we want to add back in a grey background? If so, should that be mirrored in the radio button and checkbox styles?

This feels like it would convey the affordance of 'this input is disabled' a bit clearer, but it couldn't be applied consistently without some bigger changes—particularly on File Upload components and Selects on macOS.

Should we use [disabled] or :disabled for our CSS selectors?

We use :disabled virtually everywhere in Frontend, with the exception of the Button component, which uses [disabled]. Unsure if there's a specific reason for the difference, as :disabled seems to also work on <button>s.

IE 8, however, doesn't support the :disabled pseudo-selector.

[owenatgov]

Thanks for looking into this. Very thorough as usual. From a skim of the code I don't see any problems however I have some broad thoughts:

• As you noted in the description, the disabled styles are kinda tricky to see. I'm especially worried about the form upload component. We do need some kind of minimum contest or some way to alleviate the muted colours I reckon. I wonder if there's a more nuanced way to apply the disabled styling: for the form upload targeting the button so that the border has higher contrast but the text is still muted.
• Related to the above point, it feels like a risk for us to be relying on a colour change as the only indicator that a control is disabled. I think an extra visual indicator, like the error styling with the border, would be useful here. The only thing I can think of is applying a dotted border to controls or using :before to literally add the word "disabled" somewhere.
• I'm not worried about the use of :disabled. It doesn't break anything for IE8 users in the literal sense. They can still "use" the service even if they're getting a worse experience.
• Not one for now necessarily but we should probably expand on our content for inputs. We currently on purpose don't talk about disabled styling to dissuade teams from using them but this feels like a "meet them where they are" situation. Especially if we have these attributes in here now, we should say somewhere that teams shouldn't use it ideally. Maybe in the API docs?

I think this is gonna need a designer's brain, especially on the contest and visual indication points.

All of my thoughts are tempered by the fact that we don't want teams to use disabled form controls in the first place, so our solutions don't have to be perfect but I reckon we can try to mitigate risk of teams putting together inaccessible forms.

[querkmachine]

I agree that the disabled style could benefit from a stronger visual indication. My goal here has been to not rock the boat too much and reuse the 50% opacity that we have on buttons, checkboxes and radio buttons.

If we want to investigate other ways of indicating that something is disabled, I think that whatever styles we decide should be back-portable to the checkboxes and radios (at least) so that all form inputs maintain a consistent look. A dotted border sounds doable across most input types—maybe not file input—though we could try using ::file-selector-button in supporting browsers to do something for it, perhaps?

[colinrotherham]

Some context on other "disabled" discussion here:

• Set the boolean disabled attribute consistently in the button component #2830

Would be good to fill in the consistency cracks though

One of the [disabled] vs :disabled behaviours is this annoying one:
https://www.mehulkar.com/blog/2018/01/disabled-inputs/

<form>
    <fieldset disabled="true">
        <input />
    </fieldset>
</form>

The input can be selected with CSS input:disabled but not [disabled] (CSS) or .disabled (JS)

[colinrotherham]

What does the background colour do here out of interest?

With us not having one on .govuk-input

[querkmachine]

Chrome and Internet Explorer—and only those two browsers, for whatever reasons—apply a light grey background-color to disabled text inputs and textareas. Here I've opted to remove it so that the background-color is consistent across all text inputs on all browsers.

[colinrotherham]

Ahh that's good to know

In a world of "extended components" in the various organisational-level design systems, I'm wondering if this will make some department's (blue|green|red|whatever)-tinted input suddenly go transparent when disabled?

Should background-color: transparent be the component default?

I know it came up recently didn't it in this one:

• Why do checkboxes and radios have transparent backgrounds? #1625

[CharlotteDowns]

@colinrotherham that's a good point

[CharlotteDowns]

I think this is a good addition to include labels into the change in styling of the associated form actions when :disabled. It is also good to acknowledge that the browser native styling doesn't work on all components in all cases.

I'm not sure how important legibility of :disabled components is when the intent is for them not to be used, I would hope there's some form of explanation on the page as to why something is no longer useable or active. This is I think why we discourage the use, it's hard to understand a context where a service is built for a user but doesn't allow them to do something.

I also agree that keeping the opacity consistent with radios and checkboxes is essential. Do we need to include anything about pointers or will these change my default?

[querkmachine]

I'm not sure how important legibility of :disabled components is when the intent is for them not to be used, I would hope there's some form of explanation on the page as to why something is no longer useable or active.

It’s my understanding that it’s pretty much at our discretion. The two WCAG criteria relating to contrast of text and non-text content both have exceptions for ‘inactive’ components.

SC 1.4.3: Contrast (Minimum) says:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for […] Text or images of text that are part of an inactive user interface component

SC 1.4.11: Non-text Contrast says:

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s): Visual information required to identify user interface components and states, except for inactive components

---

This is I think why we discourage the use, it's hard to understand a context where a service is built for a user but doesn't allow them to do something.

We already account for individiual inputs or options within a set being unavailable, which is why it's already possible and we have styles for disabled Checkboxes, Radios and items within a Select.

The likeliness of a disabled form controls within a service is admittedly quite low, however this is something that is more likely to be seen in a caseworking system or in a more complex user interface, such as a faceted search UI.

Like the existing styles we have for disabled controls, I feel that this is more about making sure there is a consistent baseline already present for when disabled controls are used, rather than wanting to encourage their use unnecessarily.

---

I also agree that keeping the opacity consistent with radios and checkboxes is essential. Do we need to include anything about pointers or will these change my default?

Currently this PR makes it so that all disabled form controls and buttons show the 'not-allowed' cursor type on hover. This displays as some variation of a forbidden symbol (🚫) on all versions of Windows and macOS released in the last 15 years or so.

[christopherthomasdesign]

Will try not to repeat what others have said... I basically think it makes sense to make the states more consistent and robust across components.

Like others, I feel uncomfortable with having UI components on a page that aren't legible to a lot of people (even if they can't be used). But I think it'd be a bigger and broader piece of work to look at how we style 'disabled' components in a way that all users can perceive.

[owenatgov]

Putting on my product hat, this sounds like we're comfortable with putting out a version of disabled inputs which creates some consistency and exposes the option if teams absolutely need it with a view to make it extra good in the long term but are less comfortable with the levels of legibility in their current state. With that in mind, following some design/dev collaboration between @CharlotteDowns @querkmachine I'm happy to re-review.

I've added this to the [NEXT] milestone.

[CharlotteDowns]

The understanding documentation from WCAG has a section on contrast requirements for Inactive User Interface Components.

User Interface Components that are not available for user interaction (e.g., a disabled control in HTML) are not required to meet contrast requirements in WCAG 2.1.
...
Although it would be benefitial to some people to discern inactive controls

In my opinion I think the change we are proposing here provides enough contrast to discern the component whilst also keeping it consistent with existing styling on components that we have already had to apply :disabled, in active, styling.

[CharlotteDowns]

We strongly encourage teams not to use them but if a team needs to use them this pull request improves the 'in active' styling over the default browser styling that is currently used.

We've also made sure that these styles align to those seen in other components within the GOV.UK Design System which have had to have custom :disabled styling.

[owenatgov]

Giving a technical approval plus a few opinions:

1. I think that it's worth us closing Ensure input components have consistent disabled styling #1713 and Add disabled option for input components consistently #1712 as part of this work and creating a new card to figure out what to do with disabled styles both in terms of guidance and design.
2. When we eventually revisit this and attempt to "solve" disabled styles I think it'd be valuable to distribute them as mixins the same way we do other states like link hover and focus. I'm not gonna split hairs about that now as the impact is pretty minimal.

[querkmachine]

David's had a look and is happy to progress this as-is, so I've added a changelog and will merge in a moment!