Not available buttons

December, 2021


Not available actions can create frictions and frustrating experience, most important thing is to make the reason clear and accessible. If you show a button (or any actions) but don’t allow people to interact with it, they will have to interpret why they can’t. We rarely recommend to use disabled elements because they have poor color contrast and have a development cost by adding properties to be seen by screen reader and to display a tooltip.

Actions criticality

Every item in an interface — like button — is competing for attention and straining users’ cognition. Especially in a complex interface, where lots of competing information and controls are inherent, noncritical elements make visual-search tasks more difficult. We recommend anytime it is possible to avoid to display unnecessary buttons and disabled elements.


Zoning

(1) Page's (other) actions: Secondary and third category actions. Display and hide contextually.
(2) (3) Secondary and primary actions: Secondary and primary buttons considered as important. User always need to know instantly if one of these buttons stop working or what is missing in order to perform the action.


Types of buttons

We have 3 levels in buttons hierarchy:

  • Primary button: Most important button of the page, you are supposed to have only one
  • Secondary button: Important actions, the ones next to primary button are even more important than the other secondary buttons of the page
  • Button link: Medium and less important actions

    • Primary and secondary actions


    Default

    Always keep normal state for any primary and secondary button from primary actions. Let's keep these buttons clickable (showing a guidance message on mouse-over if needed), and highlight what information is missing/wrong if/after user click if conditions are not completed.


    Primary button deactivated

    Hide button and inform user. If primary button is not currently functioning (system), this is something that all users should know about it so say it with text.


    Secondary button deactivated

    There are different usecases (Action not available at this time in the workflow, Incompatibility depending on the type of content..). Secondary button(s) from primary actions must be explained as real text. If you have multiple not available buttons, you can summarise them in one sentence.

    Page's (other) actions


    Orient design choice to avoid disabled element

    There are no deactivated UI component that could not be removed by rethinking the interaction design. You can replace for example checkboxes with radio buttons if you have exclusive choice to do. You can reduce the number of actions in your page. You can guide users by adding more steps in the flow.


    Don't be afraid to hide unnecessary buttons

    If it’s not valid, then don’t show it. Mostly true for Button links (must be considered case by case):

  • If impossible to become active
  • If not relevant with type of content next to it


    • Say it by text

    If it fits with your area and if it will helps user experience, say it by text.

    If the button is not needed for the task at hand or is very less important, it should be hidden.

    You cannot say it by text

    If you cannot say it by text (and if an action on the current screen can enable the button), use disabled state.

  • Make it visible to screen reader
  • Make it focusable on keyboard
  • Add a tooltip on hover and focus explaining conditions if user don't know them
    • Consider all aspects described above before validating a disabled button in your UI.

    You must attribute the aria-disabled="true" property to the button to make it visible for screenreader and aria-describedby property to provide a descriptive label to be displayed even from navigational keyboard. Also use disabled mouse indicator on hover.

    Table

    Hide buttons dynamically according to item(s) selection. This list of actions is conditional, meaning it can change from noting is selected to a single to a multiple selection.

    Special rights / Configuration

    Depending to user configuration, certains profils can clearly be limited (or not) to a short list of actions. Hide button as it is not relevant to display action buttons a user do not have permission to perform. In order to not get them confused with something they cannot work with, it is not recommended to list all possible actions the system is able to do with other profiles.

    Sources

  • Why you shouldn’t include disabled interaction elements in your design system by Chris Atherton
  • Frustrating Design Patterns: Disabled Buttons by Vitaly Friedman
  • Disabled Buttons in User Interface by Nick Babich
  • Is it ok to ‘grey out’ disabled buttons? by H Locke
  • Making Disabled Buttons More Inclusive by Sandrina Pereira
  • Using the aria-describedby property to provide a descriptive label for user interface controls by W3C