5

It seems best to avoid disabled controls entirely, though I realize there are sometimes technical reasons where people are forced to style some disabled controls instead of removing the fields or displaying read-only information instead. Besides these less-than-ideal situations, is it ever preferable to use a disabled input?

Also, are there documented industry standards for visual treatments of disabled controls? Accessibility should be considered by any attempt at "authoritative" work. I'm having trouble finding thorough design rationale for disabled states. Interactions are pretty well discussed (because that's mostly what disabled states are about), but visuals not as much.

  • 1
    From an accessibility perspective, it's ok to have a disabled field. While the TAB key will not put focus on a disabled field, a screen reader user can still navigate to the field by using various screen reader shortcut keys (downarrow to walk the DOM, 'E' to move to the next input field, 'F' to move to the next form element, etc). When the screen reader "focus" moves to a disable field, it will just say "disabled" or "not available" so it's clear (to the screen reader user) that they can't do anything in that field. They'll hear the value that's in the field. – slugolicious Sep 25 '18 at 14:54
3

The reasons against disabled components are deep and cross all areas. For example, disabled components have context-dependent cognitive load. Users need to know how to enable disabled components. Discovering the component is disabled and figuring out how to enable it is cognitive load. All the actions the user has to take to enable the button have compounded cognitive load. The more actions required and the further away the solution is multiply cognitive load.

UIs shouldn't need disabled components. They're a dead end. No matter how easy it is to enable them, users are turning around and going back. At the very least this is visual, but usually users have to go back cognitively and physically.

Disabled components should only be used when they can be easily enabled on the same screen within the same task.

Also, are there documented industry standards for visual treatments of disabled controls?

Material Design has a section on it in Interaction > States > Disabled

https://material.io/design/interaction/states.html#disabled

Notice that Material Design doesn't really use disabled components. They're defined but not used. If you look through the guidelines and their examples you'll see they're only used for steppers which is from the old MD guidelines.

  • Not sure I fully agree with the reasoning, but a +1 anyway for quoting a clear source. – Racheet Sep 25 '18 at 16:22
  • Yeah like I said the reasons are broad so it's hard to try to boil down. What don't you agree with? Maybe I can clear it up or you can post as an answer. – moot Sep 25 '18 at 21:31
  • In my experience, if you don't show a disabled button in multi-part forms to show there is an onward journey users often assume the page is broken. Disabled buttons can be important to signal that there is an onward journey, even if it's not accessible right now. 1/2 – Racheet Sep 26 '18 at 9:49
  • You can get round the "I can't work out how to un-disable this button" problem, by disabling controls higher up the form as well. It's much easier to understand "I have to fill this in, and the next bit of the form will become available" than "this button is weirdly gray and I can't click it, what gives?" 2/2 – Racheet Sep 26 '18 at 9:50
  • Basically, disabled buttons are an important, but situational tool in my toolkit. I'm not convinced that "UIs shouldn't need disabled components". Sometimes they're the right tool for the job. – Racheet Sep 26 '18 at 9:51
1

I think differentiating between types of input helps users to understand the way the system interacts, whether it is the result of their actions or a state set by the design of the system itself.

An input that is read-only can be clicked an interacted with, even if changing its value is not allowed. This value could be the result of a calculation between the entered values on other form inputs, and the user might want to copy it. In this case, read-only makes more sense than disabled.

A disabled input is unusable and un-clickable, and the value set is usually system generated and a way for the system to indicate that modifying a certain value is not allowed, whether it is because the user lacks the privilege, or because it's the only possible value for a given context.

  • 1
    You are correct that having a readonly field instead of a disabled field allows you to TAB to the field and select/copy text, but in many cases, it's just better to have static text instead of something that looks like you can type in it but really can't. Styling-wise, if the readonly area is in the middle of bunch of editable fields, then perhaps it might look nicer to have a readonly field instead of static text, but that doesn't happen very often. By default, a readonly field looks like an editable field so it's kind of a "tease" to the user to let them TAB there but can't modify it. – slugolicious Sep 25 '18 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.