For desktop browsers the title attribute is an easy way to explain why a button is disabled:

<button disabled title="this is disabled because ...">disabled button</button>

But as far as I know, this does not work for mobile devices.

How could this be solved for mobile devices?

  • 24
    The purpose of ‘title’ is not to provide state information, making it a horrible way to explain why a button is disabled. Your issue is - why isn’t it obvious the button is disabled? Commented Jan 22, 2021 at 6:19
  • 5
    @EvilClosetMonkey it is obvious for me, but not for the user. And it's 100% ok that they don't know everything.
    – guettli
    Commented Jan 22, 2021 at 12:52
  • 2
    Okay, I up-voted both comments. But my $0.02 is the accessibility aspect, for those with limited vision using a screen reader. And you could argue both points pro/con for my perspective! Commented Jan 22, 2021 at 20:08
  • 1
    Putting in the effort to understand why it isn’t obvious to your users and adjusting the design accordingly is the purpose of design. Slapping a message somewhere is a bandaid. It works, but it isn’t pretty; and you might need more to truly fix it. Commented Jan 23, 2021 at 1:23
  • 4
    'title' isn't just a problem for mobile users. It's a problem for everyone who doesn't use a mouse. It's an accessibility fail in general.
    – JonW
    Commented Jan 23, 2021 at 14:35

5 Answers 5


Add the same text as a small label near the disabled button.

This won't rely on any on any additional user action in order to show this additional information, which is good, because users tend only to scroll and tap when using touch screen devices.

This pattern is also not a bad thing to do on desktop also. Personally, I don't usually expect a disabled button to have a title attribute, so I wouldn't hover and wait to see if it has one. Using a little extra real estate to be transparent with the user about how they can continue moving forward is often worth it.

Mock up for mobile with text label below disabled button

  • 2
    I like this approach. It reminds me the error label used to denote which input field is mandatory once the users try to submit the form.
    – Adriano
    Commented Jan 21, 2021 at 20:49
  • Hmm, works for desktop, but for mobile there is not enough space (in my current task).
    – guettli
    Commented Jan 22, 2021 at 12:53
  • 3
    @guettli If you are able to edit your question and include a mockup or screenshot of what your mobile UI looks like, perhaps someone could provide alternate solutions that would work better. Commented Jan 22, 2021 at 13:35
  • 4
    @guettli Then put that text in an expandable section, or in an alert() behind a small "(i)" image.
    – noughtnaut
    Commented Jan 22, 2021 at 15:14

Do not disable buttons.

Disabled buttons predate modern touch screen usage and don't work in this environment.

Solution 1

For the 'I agree' or 'I have read' required checkboxes, when there is only one:

Simply put all the text on the screen. The users will see it's a TOS screen, see the scrollbar and will scroll down. At the bottom of the screen, await them with an 'Agree' button in the bottom right corner (and a 'Back' button to the left).

Surely they have read the complete text! (That's how banks do it in Germany, e.g. the Sparkasse group).

Solution 2

Instead of disabling a Next button, simply scroll up to the unchecked but required checkbox, and show all validation errors where they are needed most – right next to each control. This approach works for any form control that can have an erroneous state.

See my answer here for pictures.


  • The erroneous form control might not be visible, confusing users where they can fix 'the error' that you throw in their way.

  • Touch screens and targets can be very finicky, for example when it's raining or when you have big fingers. Therefore, providing no feedback on a click should be avoided. Users are unsure whether they simply mis-'touched', or maybe their internet stuttered?

  • Hover tooltips do not work.

  • 2
    Solution 2 would be a confusing experience for the user who doesn't understand why the page scrolled. Perhaps solvable by highlighting the "unchecked but required checkbox"?
    – noughtnaut
    Commented Jan 22, 2021 at 15:15
  • 1
    Seems like I forgot to mention that. I have included it in my answer, thanks. Commented Jan 22, 2021 at 16:22
  • 17
    ugh please don't scroll me around in my browser Commented Jan 22, 2021 at 16:53
  • 2
    If you know the "next" button has no hope of succeeding, I think it's surprising to make it clickable but do something other than go to the next screen. That feels like baiting the user into a trap.
    – Maxpm
    Commented Jan 23, 2021 at 23:18
  • 1
    This sounds obnoxious from a user perspective. If I can't click "next" because I haven't checked a box, I want to (1) know that "next" is the action to take and (2) that there appears to be a specific reason that I can't do it yet. Showing a disabled button communicates that information. Commented Jan 24, 2021 at 6:15

Mixing Everybody's good ideas into one answer for your situation: Little real-estate on a device with no hover capability.

User @Evil Closet Monkey was on the right track: why isn't it obvious? Good design involves minimizing "cognitive load", so as a general rule you should ask yourself why it's not already obvious to the user. More specifically:

If there's enough room,

the best bet is probably repeating the details right next to the button as @maxathousand suggested. Place it above the button so they must see it before the button even after scrolling.

If you can't fit the explanation near the button,

but you've explained it elsewhere, you must not be allowing the screen to scroll (otherwise, you DO have space - just let it scroll more). In that case, both the button and the original explanation will be on-screen at the same time. Draw attention to that explanation (e.g., make it red and add the appropriate aria attributes) when it's not yet met.

If you don't have enough room explain the requirement even once, there's not much you can do. You probably need to make a more significant change to the overall flow.

In any case,

I strongly recommend the premise given by @knallfrosch: don't even disable the button! Let the user press it if they think they can. From there, you can take further steps to draw user attention to the problem. You can hide the error message or keep it un-emphasized, then make it extra obvious once they have clicked the button.


It can be solved for mobile devices and non-visual users (because what you propose is actually problematic for them too, as screen readers will interpret it incorrectly) using two simple steps:

  1. Offset from the button but next to it and in it’s own HTML element (probably <div> or <span> in most cases), add a dedicated description of why the button is disabled. This should ideally call out specific errors in the form validation if at all possible. This sets things up so that most users can clearly see what is wrong, independent of their pointing device. This can have small text, but should have good contrast (please no bright red on a white background).
  2. On the disabled button, add an aria-describedby attribute pointing to the HTML element that points to the above-mentioned description. This properly links the two for assistive technologies such as screen readers.

Alternatively, the approach mentioned by @knallfrosch works here too, with one minor change: instead of jumping to the error (this can be very disorienting for users, especially non-visual users), bring up a modal dialog explaining what is wrong. Using a dialog here ensures you get the user’s attention no matter how they’re browsing. If you want you can include links pointing to the individual erroneous fields, but that’s not required.

Aside from the UX aspect, this also makes your application more efficient, as it avoids needing to check state on the form each time a user defocuses an input. This doesn’t sound like a big improvement, but it’s huge for people using keyboard navigation because they have to step through individual inputs one at a time, and doing that rapidly can trigger a slew of potentially expensive validation calls.


Thank you for your answers. They helped me to find my solution.

Sorry for the German language :-)

It says

Food can only be ordered until 8am

I just don't disable the [+] [-] buttons which can be used to order food.

I show a Lock symbol and a Bootstrap5 Popover. If the user wants to know why the row is locked, he can click on the lock-symbol to see the explanation.


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.