I’ve been using a password manager for some years and sometimes I also use the “use a securely generated password” function in it or in my browser. And I’ve noticed that when forms have their submit buttons disabled and we use this feature it often does not enable the button at all.
Skip to demo at the end if you want to test it for yourself.
Now, while this is not a directly failure of WCAG – success criterion 3.3.8 Accessible Authentication (Minimum, Level AA) comes to mind (opens in new window), I am definitely flagging this as usability issue in my accessibility and usability audits.
However, if user agents and password managers are actively blocked from filling in the fields (for instance, by a script that prevents form fields from being automatically populated), or users are prevented from copy and paste operations (as they may rely on standalone/external third party password managers), then the page would fail this criterion unless an alternative is provided.
WCAG 2.2, success criterion 3.3.8 Accessible Authentication (Minimum, Level AA) on login forms is relevant if page is actively preventing the password manager, but has not flagged the disabled button related issue I am writing about.
I have made my share of forms and am still making them. I have used the disabled button pattern a lot of times in the past, mostly by the instruction of the designers. Sometimes because I was lazy and I didn’t want to add the user experience logic to inform the user about the issues even when form was not valid.
So I know that disabled buttons are just a sign of being lazy and being fast. If you use AI for coding and you got a disabled button solution like this – you AI is reeealy lazy as well and I recommend teaching it with some persistent instructions or skills to never use the disabled button pattern again!
But if you really can’t go against it and a disabled button is kind of your only option, we can perhaps still do something to improve the experience just a bit.
If there is no other way and the button really needs to be disabled
Sometimes we still have to live with some solutions that are out of our hands to improve or change a lot. In this case, if we can, we should at least try to improve the user experience.
If your hands are tied – at least explain in text
As a minimum, I suggest at least informing the users in text, before the form. As some assistive technology basically removes the disabled buttons it may be beneficial to at least know about it. “Submit button is disabled until form is valid” can mean a big difference for some people.
If you can change the JavaScript
If we have the access to JavaScript for the form, but still need to use the disabled button, then make sure fields are listening to input events, and not only keyup and similar ones.
The “use a securely generated password” function does not trigger a keyup. That makes the form kind of valid, visually, but the script has not detected the populated values and considers the fields empty. And disabled button is therefore still disabled. And user has no clue – it seems that the form is broken as it does not react to the input.
Definitely test with different password managers or at least different browsers that offer this solution (Firefox does and many others as well).
Or – just go against the disabled button and at least show an old school alert message like it is 1995. It works way better than when people guess and struggle and probably just go away if they can.
Disabled buttons should be a thing of the past
There are some border scenarios where a disabled button is viable. Like Previous button in pagination where we are already on the first page, or a quantity stepper at its minimum and so on. If we can’t just hide the button for visual harmony, we can use the aria-disabled="true" instead of disabled HTML attribute, to at least allow tabbing to it.
But I guess that in most cases it is better to leave it active and inform the users properly. It often depends on the context as usual.
So I really hope that at least disabling submit buttons based on validation rules is soon a thing of the past.
Demo forms
These forms do not send any data anywhere and are not production ready in any way!
They only demonstrate the bad (Form 1), better (Form 2) and even better (Form 3) user experience of the submit button – and allow you to test with your browser or password manager to populate passwords automatically and then toggle the disabled state (with form 1 and 2).
Forms 1 and 2 disable the submit button until the two passwords match. Try each one twice: once by typing, and once using your browser’s “suggest strong password” / autofill.
Form 3 does not disable the submit button – it provides feedback in all cases.
Forms 1 and 2 differ only in the JavaScript event name passed to wireForm().
Form 3 keeps the keyup event (best-effort, still misses autofill) but never disables the button on it — the real check runs on submit, reading the current field values, so how they were filled is irrelevant.
So – once again – you do not need to disable the button, but if you really must – make sure it works with all modes a user can use the form!
