Disabled States

There is some debate about whether we should use disabled elements in Vega.

Disabled states are versions of elements which indicate that a button or field is not interactive. In other words, and is deemphasized within the user interface. They are typically displayed as grayed out, or with a lower percentage of opacity than an enabled state.

Arguments in favor of them include statements that they can help prevent submission of forms with error conditions, or will serve as an indicator to users that information needs to be completed on a form.

Problems with Disabled States

Not everyone knows about the disabled state

If a user who is unfamiliar with the concept of a disabled button encounters one on a form, it may lead them to the assumption that the form itself is broken. This can cause confusion and frustration among many users.

Poor visibility for some users

On buttons, with gray text over a gray background, these can be difficult to see for many users. If we adjust these to adapt to WCAG guidelines (with a greater contrast) it may counteract the point of a field being disabled; it will appear as a regular field and can cause some of the same frustration as in the previous point.

Ambiguity

Using a disabled field or button to indicate the incompleteness of a form is an indirect form of communication. If a user encounters a disabled field, it requires them to think about why the field might not be working; it is not immediately clear in the way that text instructions would be.

Navigation of Forms

For non-sighted or limited-sight users who are reliant on a screen-reader to be able to consume the contents of a screen, disabled buttons will not be typically recognized by these devices as fields which can be interacted with. For someone who is sighted, there may be some understanding of the purpose of a disabled input, but this can be completely lost by those who cannot see the screen. Similarly, for users who prefer to navigate a site using a keyboard, disabled fields will typically be skipped while tabbing through a page. This can cause some frustration and/or confusion.

Alternatives to a Disabled State

Hide fields

If a field should not be interacted with under a certain condition, it can be hidden.

Text

When necessary, use a textual explanation to explain why a field is not available.

Validation

In cases where it is necessary for a user to perform a specific action prior to submitting a form, it makes more sense to use validation to prevent incomplete form submissions.

Edge Cases

It is understandable that there are cases where one might still want to use a disabled field. We offer the following alternatives.

Preventing Invalid Responses

In circumstances where certain inputs become invalid, it might be tempting to use a disabled field (e.g. conditional answers to a form, where these are dependent on a positive or negative response to an inquiry).

Solution: It’s quite easy to hide irrelevant questions from a user using a CSS display:none attribute. If a circumstance is more complicated, you may use text to explain the difference.

Option currently unavailable

In a circumstance, such as scheduling an appointment, there may be a desire to disable options which are no longer available (e.g. if a time has already been booked by someone else).

Example: If a user visits a page for the first time and all slots are booked, how would a user know whether the slots are booked, or whether the form functionality is buggy?

Solution: The solution, in most cases, is to hide the options which are no longer available. When the information is required to be displayed, you may also show these options to users for clarity in plain text on a standard background rather than as a form option which cannot be selected, separating non-interactive elements from interactive elements.

Acknowledgement of TOS

In many forms, it may seem common to disable the submit button until a user has checked that they have read the terms of service, or any sort of disclaimer.

Solution: Instead of disabling the submit button, this can be handled with some simple form validation, both with text and possibly an alert which will prevent a user from submitting the form unless the specified condition has been met.

Prevent an error condition in code

In some cases, developers may be tempted to limit the user’s behavior by using disabled fields to prevent incorrect information being submitted to the back-end.

Solution: This approach is similar to putting a “bridge out” sign on a road instead of fixing the bridge itself. In general it’s best to create multiple methods of error validation, to prevent errant submission of data.

It is, however, permissible to use a disabled field as an extra check if this field is also hidden from the user. It is considered best practice to create multiple levels of validation in code, both on the front and back end. We can avoid using disabled elements in our interface by using proper error checking or halts in data submission processes to prevent bad data from entering a database.

There is no reason to display a visible disabled design component to the end-user because it is not focusable for a sighted user. Disabled elements also can cause problems and confusion to non-sighted users.

Best Practices

There may be instances where we may, for a number of reasons, be forced to use disabled form elements. Below we will outline some best practices for using these where they may be necessary.

Use only in intermediate states

Don’t use disabled or read-only when in a starting state, but only in an intermediate state. For instance, we may wish to display a user’s email address, which serves as a primary key for identification purposes. We don’t want users to be able to change an existing email address for this purpose, so we can display it but make it disabled. This goal, however, can be accomplished by displaying the email address as text, and not as part of the form

While form is submitting

It may make some sense to disable fields while a form is in a submission state. This can serve to prevent users from changing or believing they are changing input data that has already been sent to the server, particularly if this is a slow process. For non-visual users, it may be necessary to provide an ARIA alert to let them know that the form is in the process of submission.

Already submitted form

Once data has been submitted to the server, it may be worthwhile to present the user the information that they have submitted; it can be displayed within the form format to show what values they have submitted, but to not allow changing these values. In this case, it’s better to use read-only instead of disabled states.

Hide the disabled field

If you are using disabled fields to prevent error conditions, it may be best to hide these fields as well, so as to not introduce any additional user confusion.

Include additional information

In the likely event that a user will attempt to click on a disabled field, it’s best to provide some sort of explanation to the user why doing so will not result in any action. You can provide either tooltips or mouseover effects to let the user know why a field cannot be changed. You can also include some explanatory text on the page.

Provide instruction to screen readers

By using ARIA labels, you can provide instructions to screen readers on what to do about disabled fields.