I was wondering if you could help me with a UX issue I am facing with “disabled buttons in Mobile”

We have a few different input fields as part of a mobile onboarding process. These forms have quite a few fields and we currently disable the next button until those fields are all filled out. But, if the user taps on the disabled button, it will display an inline error message on the not filled out input fields.

We've been debating whether it's a better user experience to show feedback when the user taps on the disabled button to show that something is missing or if disabled buttons generally should never have any reaction as they are disabled.

  • 4
    In your case disabling buttons is an anti pattern. This answer on a different question explains why and probably answers your question: ux.stackexchange.com/a/126458/36883
    – jazZRo
    Commented Jul 9, 2019 at 9:51
  • 9
    excuse me, but it's "event challenged" buttons... ;-)
    – Michael
    Commented Jul 9, 2019 at 22:39
  • 4
    If a non sight diminished user tries to click your disabled button. Then you have failed badly at disabling the button visually. If you want the user to be given feedback when they try to go to next incorrectly, leave the button enabled. Otherwise, disabled buttons can’t be clicked. Like clicking the background of the body. No effect. Commented Jul 10, 2019 at 5:18
  • 1
    You might benefit from this similar question.
    – Kit Grose
    Commented Jul 10, 2019 at 8:00
  • 3
    There is feedback and warning on the upvote buttons here when you try upvote your own question...so someone told me.
    – teddy
    Commented Jul 10, 2019 at 23:16

9 Answers 9


In the end, both ways lead to the same result. Whether it's an inline error or maybe a bubble with feedback, the user gets to know why he can't proceed (which adheres to visibility of system status).

The point about disabled elements never having an action is understandable, but strictly clinging to this rule is not really of service to the user. If he could have a better UX with your product for the small price of not adhering to a rule 100%, I'd say it's worth it. You're not completely breaking it anyway, just slightly deviating from it.

With that being said, I personally think giving this feedback this way could be considered more modern or "cooler". So, especially if you're targeting a younger audience, I'd say it would be an improvement.

One drawback here can be that some users, who are very accustomed to the "old ways", could potentially find this unexpected and thus annoying. But that seems like a rather small chance.

Also another thing to consider: Users with visual impairment. Their screenreaders can catch inline error messages just fine (as far as I know), but a speech bubble might be tricky. At the very least, it should then simply grab system focus upon appearing.

Something like this seems to be a good way of doing it:
A disabled button showing a speech bubble with reasons on why it is disabled

You can either show it on click of the button or have a smaller (?) button placed on top of it, which in turn doesn't break the disabled button rule anymore.

  • 3
    This shows perfectly the problem with disabled buttons. Why would you hover a button that is disabled? It won't do anything (unless you already know it will show the extra info). Also the contrast is way too low.
    – jazZRo
    Commented Jul 9, 2019 at 9:56
  • 10
    @jazZRo I don't think that argument holds against a disabled button with an extra affordance on top of it in form of a help button. Though, the contrast of the help button should probably be stronger to show that it is usable, unlike the main button itself.
    – Big_Chair
    Commented Jul 9, 2019 at 10:09
  • 2
    There can be a simple info box explaining that the user can't be deleted and why. Sorry but I have seen buttons like this fail in usability and accessibility tests.
    – jazZRo
    Commented Jul 9, 2019 at 10:32
  • 1
    I also think you can't speak of extra affordance. Even when the help icon has a high contrast, the contrast of the button (text) remains too low. And I wonder if the visual connection between the button and the help icon will be clear, let alone the meaning of both.
    – jazZRo
    Commented Jul 9, 2019 at 10:36
  • 1
    @jazZRo You're probably right, a simple box at the top or bottom of the page/form explaining would be more clear. But then again, what if you have 10 buttons and 5 are disabled? You'd have to write extra logic for a summary message or single message etc. But for a few buttons only it'd work.
    – Big_Chair
    Commented Jul 10, 2019 at 7:46

If this weren't mobile, I'd say it would be better to have a message shown next to the disabled button saying

Please fill in the remaining required fields (marked with *)

or some such (wordsmithing required).

But for mobile, where you don't have that real estate, having the button active (not disabled) and having it tell the user what fields they still need to fill in when clicked seems reasonable. I wouldn't make the button disabled but still responding to clicks, but perhaps it could say (Can't send yet) vs (when all required fields are filled in) Send.

Don't forget accessibility. There are various things you can do there. One of them is that you can make the "hint" the visually-impaired user hears for the button different, and longer, than what's shown visually, if the user is using the popular screen readers for mobile (VoiceOver for iOS, TalkBack for Android). Details here and here. For instance, the message could say "Please fill in the first name, lastname, and email fields." Be sure to test with screenreaders.

  • 1
    On iOS and VoiceOver, hints like this IMO are actually not recommended because they add clutter. VoiceOver will read a send button with .disabled = true as "Send, dimmed". This is both much more economical/faster to process and is used frequently in stock iOS and so very familiar.
    – Allison
    Commented Jul 10, 2019 at 16:56
  • @Sirens - Well, this article seemed to think they were underused. Not really my area of expertise. It's just that listing the fields that need filling in if the user focuses the button seems useful (but only if they focus it, otherwise it...will tend to go on a bit :-) ). Commented Jul 11, 2019 at 6:37

This is how the Google sign-up process does it. It should be very similar to your process. Note that the primary button is always enabled, it only changes its function!

  1. You are presented with a pretty self-explanatory form

empty form

  1. The Next button has the primary color and can be clicked. Note that the secondary button takes you to a completely different process (sign-in in this case.)

Active next button

  1. After submitting the invalid form via the Next button, you are scrolled to the first invalid form and all controls are validated (even when they are not dirty.) You will thus see all invalid controls on your way to the Next button.

Invalid controls

The only difference to you is that you seem to have optional fields. You could mark these with (optional) or gather them in a completely optional form which, in addition to a Next, has a Skip button (This is very often used for phone numbers.)

If your form grows too big, think whether all required data is really needed at sign-up. If the user himself triggers actions that require more data – such as a purchase at an online store – it is better to only then require a payment method and address.


Going by the concept of 'informed decisions', it is always better to provide users with enough directions so that they do not make any mistakes instead of letting them find out that what they did was all wrong. If the form fields have required marked on them with an asterisk * or in some other way along with the other design intentions, the form will be filled correctly and there should be no need to disable the submit button. I recommend not using disabled buttons unless really required.


To me, it looks like you haven't actually disabled the "next" button, just toggled its behavior. So instead of

enabled (action a) ↔︎ disabled (no action)

you now have

enabled (action a) ↔︎ enabled (action b)

That in itself isn't necessarily a problem unless you render it as actually disabled. If you do, your users will expect other "disabled" buttons to have behavior. When they encounter an actually disabled button (i.e. with no behavior), they might get the impression that the button is broken, since the expectation is that "disabled" buttons shall give feedback (or at least have some action).

This is, as I understand it, your current solution:

current solution

The user doesn't get any indication of which of the two last buttons will react to interaction.

Consider instead a visual distinction between "enabled", "disabled-but-not-really" and "disabled-for-real", e.g:

proposed solution

This way you have a distinction between ordinary state, feedback state and actually disabled.


By observing how users use my app I've seen that disabled buttons are still pressed by a significant portion of users, especially those who are less technically acquainted. This happened even when the disabled button was clearly greyed out.

My solution typically is to indeed trigger a validation response if a disabled button is pressed. From observing behavior before and after implementing such validation message this indeed had the desired effect.

The other solution is to not disable the action button, and have a validation message show as it normally would (example on stackexchange).


I think the way you have described it makes sense. I would include an asterisk on all the required fields, even though they are all required. You could even have a note at the top stating all fields are required. Anything to help the user understand what to do on a complex form is best.


Since in mobile vertical screenspace is (almost) unlimited, I would just add a permanent visible message just above the disabled button.

You need to fill out name, mobile number and agree to our T&C before you can continue.

Since the message will only appear if someone scrolls down to the Next-button, it will only be visible to users reaching for the button without having filled out all necessary fields. And you can leave the disabled = no reaction policy intact.


I would do some usability testing first to see if any of this even matters. You can't ensure a great user experience without including the user, right? Do some usability testing to see if users get confused as to why the button is disabled. Your particular users might understand why it's disabled and this could be a non-issue. Adding help bubbles or other stuff is just adding complexity to your interface that you don't know you need.

If your users are consistently clicking on the disabled button, then you have to determine why. Are they clicking because it doesn't look disabled? Maybe it's a visual affordance issue? Are they clicking because they are accidentally skipping one of the required fields? I had this happen once where the user had to check the box to agree to the terms and with all the other content on the screen, they didn't see it. Then when they got to the end of the form, they didn't understand why the button was disabled.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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