Disabled/Non-Editable Components

The properties of the disabled attribute:

• the input will NOT have a tab stop
• the input will NOT be focusable
• the input value CANNOT be changed without JavaScript
• the input CANNOT be submitted in a form

The properties of the readonly attribute:

• the input WILL have a tab stop
• the input WILL be focusable
• the input value CANNOT be changed without JavaScript
• the input CAN BE submitted in a form

• Make use of the disabled attribute when a form has been submitted. This will prevent the user from updating any information while the submission process is happening.

1 Avoid using a disabled or readonly component in a starting state.

Example scenario:

- A form that contains a user's information. - We do not want to allow the user to change their email address - But they do need to see the email address to ensure it's correct

Usability Issues with this scenario:

- What if it's the wrong email address. If this component is displayed as an input box, the user will assume it is in someway editable. This will frustrate the user as they don't know how to edit the field.

The Solution:

- Show the email address as regular text and provide a help message for how to proceed if the email address is incorrect.

2 Don't disable the submit button

• Sometimes a form will disable the submit button until the user has filled out all the required fields.
• This doesn't provide any feedback to the user. They do not know how to enable that button. This adds to the cognitive load of the user.
• Keep the button enabled so the user can press it and then be shown the errors on the form.
• The only time a disabled button should be used is if there's no other way to proceed on a single form field
• Avoid using the generic term Submit on the button. Use a term that more appropriately describes the action being performed.

• Disabled buttons increase the user's cognitive load and can prevent them from completing a task.
• Discovering the component is disabled and thinking about how to enable it adds to a user's workload. The more actions required to complete a task multiplies the cognitive load.
• A UI shouldn't need a disabled component unless it can easily be enabled on the same screen. Disabled components are generally a dead end as far as navigation is concerned.
• Not all users understand the conventions of a disabled button or other components.
• As a result, they will click a button and won't know why it isn't working which will cause them frustration.
• A disabled button that can't be interacted with will task the user with figuring out why it won't work. This adds to the cognitive load of the user.
• Keep in mind users who use screen-reader technology
  • They won't be able to see disabled elements so won't even know they exist on the screen.
  • Also, consider the order the components appear as screen-readers will work in a linear fashion.

• Ask yourself why you're using a disabled component
  • Are there different and better ways to display this information?
  • Don't make them a part of your design system as there are almost always better ways to implement things.
• If you have to disable an option, explain why it's disabled i.e. a morning appointment is not available on the date you've selected.
  • Allow the user to step back in the process if they have made a mistake.
• Avoid simply using a grey color for a disabled button. In the user's mind, this may look like a selectable button so when they press it and nothing happens they can become frustrated.
• Instead of a color change, reduce the opacity of a button to denote it is inactive. This allows the user to see the button is similar to the active one and therefore disabled.
• Reduce the opacity enough to show the button is inactive < 40% opacity depending on the background.
• Place the disabled button next to enabled buttons to help build the user's mental model of how these buttons work.
• Add supporting text to add more clarity to the button
• Don't change the font size of disabled buttons