Recent searches
Search options
At GOV.UK we avoid disabling buttons.
If the user submits a form with a problem, they get a useful error message telling them how to fix it.
Disabled buttons are hard to make accessible for people with low vision, and can't easily be focused using the keyboard
@joelanman Agreed, just tell me what I did wrong instead of making me go back through the entire form again to check every field.
@joelanman I like this but find myself being pushed to disable buttons. Have you explored using the button space to show any errors where the user will be looking in order to progress –they might avoid a failure and the wait for a new page to load?
Interested in what you think and if you’ve tried it.
@del
I have — at the behest of a client.
Users found it confusing and assumed the page layout was broken.
@del Yeah I think people who disable buttons often want to rely on inline validation but it's such a hard pattern to get right. When are people done with their input? How do you make sure screen reader users are definitely aware of it. You have to keep it synced up on terms of rules with your back end validation. It adds to page weight. So many things to navigate for little value
@del and still you can't be sure some people won't try and click the button and get no feedback, and some people can't even read it if it's disabled
@joelanman With all my respect, I disagree: If a button is disabled, I know for 100% that something is wrong in my form (most of the times it's the wrong phone number format or a forgotten obligatory checkbox). I'm totally blind.
@menelion thanks, however it is a problem for many other people, so its simplest to give an error message telling them how to fix it. Out of interest how do you focus the disabled button?
@joelanman I don't focus it with Tab, of course (it's not focusable, as you pointed out). I either navigate with arrows, or press the B key (works in both JAWS and NVDA on Windows).
@menelion good to know thanks!
@joelanman Good to note, I wasn't aware of this and looking back at my previous job, we used disabled buttons a LOT. Thanks for the tip, it'll be very useful in the future!
@joelanman Ive always disabled the submit button until the form is valid, and provided feedback within the form itself as to what is needed (usually on blur). Is that not the right way?
@robert I think there's always the possibility someone might not understand why the button is disabled - for example they miss a field for whatever reason. Also inline validation is so hard to get right for everyone (people who use screen readers or magnifiers for example) and you have to write server side validation anyway, and then you have to keep both sets of validation rules in sync
@robert oh and everyone has to load and run the extra javascript, but hopefully most people won't need it, so a performance hit too
@joelanman Sure, but immediate feedback is better than an error message that only appears after an attempt to submit. Error messages right next to the form field they relate to are better than a to-do list in a modal window.
Maybe instead of completely inactivating the button, it should blur all fields and show their validation messages, the same as if the user had entered and left without completing them?
@joelanman I could go on here - yeah you need the same rules on the server and client but their purpose is different. On the server you need certainty that your business rules are followed and your database is consistent. On the client you need accessibility and intuitiveness. You make different tradeoffs in both circumstances.
Good UX design is hard to get right, that doesn’t mean you shouldn’t bother.
@robert Good UX is exactly what I'm aiming for, I think we just disagree how
@joelanman I feel like I’m misunderstanding you. Are you saying we shouldn’t bother with inline validation messages? That waiting for users to submit an invalid form to then return some kind of modal with a to-do list is better? If so, I disagree:
- requiring users to remember instructions is bad design
- feedback should be specific to its associated field, not the entire form
- on field blur is the best time to give feedback because then the user’s focus is already there.
@robert Disabled buttons have proven to be problematic. The basic idea is: where you had a disabled button, leave the regular button and instead of triggering the action, warn the user.
The particular pattern you're using doesn't matter. So why not keeping your pattern and replacing the disabled button with an action informing the user of why they can't submit?
@martinm That makes sense, I like that advice. Should I still grey it out? Give an indication that it’s not ready yet?
@robert greying out is problematic because of contrast as mentioned above. It also is a convention for disabled buttons so visual users would probably assume they can’t click. A info message under the button would work better in my opinion…
@robert @robert the core idea is to have the button do something instead of nothing. then you can build your pattern from there. Giving feedback earlier is a nice improvement, which is what the info text would do. Changing the button text may be another possibility in some cases (although I can’t see it working in the context of forms)
@martinm by “greyed out” I either mean a dark grey or a darkened and desaturated theme color with white text, and then when the form is valid I transition it to whatever the primary theme color is. Good contrast in both cases.
I think it’s a good idea to validate all fields on click and show any messages that were hidden up to that point. I’ll be making that change in the future, thanks!