Provide a disabled style for text inputs [DISCUSSION]

[edwardhorsford]

Similar to #367, should we provide styles for disabled inputs? With our current styles there will be no visual difference if an input is disabled, which is not good.

Services will either have inputs that are identical but don't actually work (confusing) or come up with their own designs (inconsistent.

We do not recommend the use of disabled elements, but that doesn't mean they won't be used. There may also be situations where they can't be avoided - a 3rd party payment interface, for instance.

How would you expect it to work?

Disabled textboxes should have some visual difference when disabled.

How does it work currently?

Disabled inputs look identical to non-disabled inputs

Feel free to suggest a fix...

An example with the colours knocked back and a grey background applied.

[fofr]

How about removing the border and background and styling as text? It is not an interactive element, so it doesn't need to look like one.

[edwardhorsford]

@fofr normally we'd recommend doing something like that if an option wasn't available, but probably including changing the labels.

I wonder if it works ok if the label is a question. Thoughts?

Example:

[NickColley]

Would that be a readonly input though? I guess the boundaries between disabled and readonly are subtle.

[NickColley]

https://www.w3.org/TR/html4/interact/forms.html#h-17.12

Interestingly

Read-only elements receive focus but cannot be modified by the user.
Read-only elements are included in tabbing navigation.

[cjforms]

As @timpaul pointed out, these 'disabled' things are mostly (entirely?) for admin interfaces where some of the considerations are different.
But - thinking about the situation where they might appear in something for the general public - I'd much rather see the thing styled as plain text (or a variation on it) than as a thing-that-looks-a-bit-like-a-widget-to-interact-with-but-isn't-really. Because the poor general public get enough of that from websites where designers are trying to be clever and styling things that really are widgets to interact with in 'innovative' ways - so they don't know whether a strange styling means 'you can't use this' or whether it means 'we're trying to look cool'.

[joelanman]

We also need clear guidance on avoiding disabled text fields in favour of simply showing the text on the screen, say as a <p> tag.

[philsherry]

This just came up in Slack, so I'll post thoughts here.

Okay, so the summary here is “If it can be set, we should style it”. I think that’s valid, but having them on show in Elements might give people the wrong ideas about using them. We can avoid that by styling them but not showing them.

[edwardhorsford]

@philsherry I think this has three downsides.

1. If it's not mentioned, people won't necessarily know we don't support it's usage. We previously didn't mention selects, but that means people looking for them weren't told they shouldn't be used.

2. I expect people browse elements to know what styles we have and what we support. Someone very likely might visit elements and search for disabled, only to find it isn't there. Is this ok?

3. I often visit elements to grab styles to use in designs. Do we want to prevent designers or non coders from knowing they exist and what they look like?

---

In summary, I believe Elements / our future design system will have to have entries for all common elements, even if all it says is to avoid using a thing.

[36degrees]

The Elements interface is also used by people making changes to things as a sandbox to make sure they’re not breaking something. Removing them from the interface makes it a lot easier for people making changes to forget about e.g. disabled states and accidentally break them.

I hope that the separation we will have between Frontend and the Design System (implementation details vs guidance and best practise) will make this clearer in the future, but it’s something we’ll need to look out for.

[philsherry]

All valid points, of course.

In that case, should disabled elements require extra justification during assessment? If someone is using one, they really need to back up that usage with UR data.

[edwardhorsford]

@philsherry I think / hope that's already the case. I'd certainly raise it if I thought they were being used inappropriately.

[philandstuff]

@edwardhorsford autocomplete fail there, think you wanted @philsherry

[36degrees]

Following the launch of the GOV.UK Design System, GOV.UK Elements will now only get major bug fixes and security patches, so I'm going to close this.

I've copied the initial comment and referenced this issue in the backlog issue for text inputs.