User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
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?
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.
alert() behind a small "(i)" image.
Jan 22, 2021 at 15:14
Disabled buttons predate modern touch screen usage and don't work in this environment.
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).
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.
Reasons:
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.
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:
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.
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.
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:
<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).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.
