Button disabling vs hiding

[mma1504]

team - trying to double check my understanding of Paste's position on disabling vs hiding buttons. Segment has many, many examples of disabling buttons and attaching a popover that explains why they can't use it and what they can do (if anything) to change that).

• In the button component guidance, it says to use this sparingly and instead the desired behavior is to leave it enabled and available, and show an error message if they try to click it.

• In (Popover/Tooltip doesn't appear on disabled elements segmentio/evergreen#1542 (comment)), it seems like the popover isn't accessible and wouldn't be read by screenreaders, so that's undesirable behavior.

Many times, the reason we're disabling buttons is because of access issues, which we explain in the popover. I'm not sure hiding the buttons would be useful, since some users may not know there could be buttons there if they had different permissions. Given the above guidance, is the desired and most accessible design, then, to leave the buttons clickable, and throw an error that they don't have the right permissions?

[SiTaggart]

Hi @mma1504 great question!

is the desired and most accessible design, then, to leave the buttons clickable, and throw an error that they don't have the right permissions?

The short answer is, yes, this is what we'd recommend.

A better solution might be to explicitly call out access limitations on the page before you start interacting with it. Just because a button is disabled, doesn't mean you won't waste a bunch of time doing something on the page you can't do or save. It's much better to place a callout or alert on the page telling the user up front that they can't do something on the page and give them ways to either unblock, or guide them to a resolution, and not hide that from them.

Whether the button is disabled, or hidden, or enabled, the fact that I can do something I'm not actually able to do, and I'm essentially guessing, might lead to more user friction.

Regarding disabled buttons, they are rendered inactive. They can't perform any user action, even down to being focused. To assistive technology users they aren't even easily discoverable on the page as disabling something effectively just removes it. Why have something there that can't be used? This is the reason we don't allow interactive disabled elements in Paste.

[mma1504]

Thank you!!

[char-mainewang]

Hello team, in scenarios where users engage in an editing process within a Wizard flow with a Save button, would it be advisable to disable the Save button when no changes have been made, and just leave the "Cancel" button active?

I understand that disabled buttons are not ideal as they're not accessible, but I'm worried that letting users click the Save button followed with presenting an a toast might cause confusion. What are your recommendations for handling this situation?

[SiTaggart]

As per the guidelines in the wizard template, we still recommend not disabling the buttons in the actions.

[kevinbtu]

Adding my perspective here for the scenarios I've seen in Segment.

There is a difference between an error/incomplete state vs. not having the permissions to do something. Speaking at a higher level, that corresponds to whether or not the user can take action to resolve something.

In the example of the former scenario (error/incompletion), I agree that it is more helpful to enable the button and display an error or explanation on click. That avoids the user having to hunt around and figure out why the button is disabled (e.g. i'm thinking of all the states in Segment where the "Next" button is disabled because the form / inputs are not complete or have an error).

In the example of the latter (where you don't have access due to your role), it's a little more nuanced. I lean towards hiding the CTA, since there's nothing the user can do to change that state. And, in the vast majority of cases someone's permission doesn't change. The exception perhaps is if the user can self-serve request access or a change in permission through the app. Otherwise, showing an enabled button here and always displaying a message after click that the functionality is not available is poor experience.

The other rule of thumb I generally follow is to consider whether or not the state will change often. E.g. will I sometimes see the button enabled, and sometimes disabled? If so, then maybe the CTA should be present all the time so I know it's there. But if that's not the case, then it's more clutter to always see a button, whether it's disabled or enabled.

[SiTaggart]

Love that perspective, nicely articulated nuance!