Ensure input components have consistent disabled styling

[NickColley]

What

Some input components do not look disabled when tested cross-browser, we should try to add styles to input components to makes sure there is an intentional disabled state that works across browsers.

Why

We don't recommend users disabled their inputs but if they do we want them to be as usable and accessible as possible.

Who needs to know about this

Developers, Chris

Further detail

If possible, contrasts should aim for WCAG guidelines to level AA but this is not a requirement.

See this related issue for more context: #1692 (comment)

Done when

• File upload has disabled styling
• Select has disabled styling
• Text input has disabled styling
• Textarea has disabled styling

[timpaul]

"I wonder if styling the disabled button with cursor: not-allowed would provide more affordance to the user?"

Originally posted by @jesseyuen in alphagov/govuk-design-system-backlog#34 (comment)

[edwardhorsford]

Another to add: items in autocomplete have disabled styling (for when enhancing a select). It's common practice to have the first item be disabled and something like Select your foo.

[querkmachine]

I've been looking into this as a random side thing. As we currently rely on user agent styles for disabled states, we have quite a lot of inconsistency in how they appear across different browsers. In some cases, disabled inputs don't appear visually distinct from enabled ones whatsoever.

Based on checking the most recent browsers (and IE 11), when compared to their default, non-disabled versions:

Browser (and OS) tested	Text input/textarea	Select	File upload
Chrome 109 (macOS and Windows)	Reduced contrast on text, light grey background added	Reduced contrast on text only	No visual differences
Safari 16.0 (macOS)	Reduced contrast on text only	No visual differences	Reduced contrast on “Choose file” button only
Safari 16.1 (iOS)	Reduced opacity on entire input	Reduced contrast on arrowhead icon only	No visual differences
Firefox 108 (macOS and Windows)	Reduced contrast on text only	No visual differences	Reduced contrast on “Browse...” button only
Edge 109 (Windows)	Reduced contrast on text, light grey background added	Reduced contrast on text only	No visual differences
Internet Explorer 11 (Windows)	Reduced contrast on text, light grey background added	Reduced contrast on text and arrowhead icon	Reduced contrast on “Browse...” button only

For how we might style these disabled inputs: we currently only provide explicit disabled styles for checkboxes and radio buttons, as we've deviated from using native controls for them. In this case, we've reduced the opacity of the control by 50% and otherwise made no stylistic changes.

I think the same approach can work for these other inputs, though we also need to reset the background and text colours on some of them to account for different user agents applying different default styles. These styles seemed to work consistently across the board in my informal spike:

/* Text input, textarea */
:disabled {
  opacity: .5; /* overrides UA style - Safari iOS */
  color: inherit; /* reset UA styles - all browsers */
  background-color: transparent; /* reset UA styles - Chromium, IE */
}

/* Select */
:disabled {
  opacity: .5;
  color: inherit; /* reset UA styles - Chromium, IE */
  /* We explicitly _don't_ set a `background-color` for Safari iOS, as this changes the default `appearance` for... reasons? */
}

/* File upload */
:disabled {
  opacity: .5;
}

Naturally, this needs more extensive testing for accessibility, high contrast colour modes, etc. so don't take those as gospel. Just getting thoughts down whilst they're still in my head. 🤓

[querkmachine]

An MVP version of this has been shipped in #3187, however we're still interested in researching and iterating on disabled styles in the future. A new issue has been opened to that effect:

• Research improvements to disabled form control styles #3323