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.<\/p>\n\n\n\n
Skip to demo at the end<\/a> if you want to test it for yourself.<\/p>\n\n\n\n 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)<\/a>, I am definitely flagging this as usability issue<\/strong> in my accessibility and usability audits<\/a>.<\/p>\n\n\n\n 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.<\/p>\nWCAG 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<\/strong> related issue I am writing about.<\/cite><\/blockquote>\n\n\n\n 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.<\/p>\n\n\n\n So I know that disabled buttons are just a sign of being lazy and being fast<\/strong>. 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!<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n As a minimum, I suggest at least informing the users in text, before the form.<\/strong> 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.<\/p>\n\n\n\n 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 The “use a securely generated password” function does not trigger a Definitely test with different password managers or at least different browsers that offer this solution (Firefox does and many others as well).<\/p>\n\n\n\n Or – just go against the disabled button and at least show an old school 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 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.<\/p>\n\n\n\n So I really hope that at least disabling submit buttons based on validation rules is soon a thing of the past.<\/p>\n\n\n\n\n
If there is no other way and the button really needs to be disabled<\/h2>\n\n\n\n
If your hands are tied – at least explain in text<\/h3>\n\n\n\n
If you can change the JavaScript<\/h3>\n\n\n\n
input<\/code> events, and not only keyup<\/code> and similar ones.<\/p>\n\n\n\nkeyup<\/code>. 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.<\/p>\n\n\n\nalert<\/code> message like it is 1995. It works way better than when people guess and struggle and probably just go away if they can.<\/p>\n\n\n\nDisabled buttons should be a thing of the past<\/h2>\n\n\n\n
aria-disabled=\"true\"<\/code> instead of disabled<\/code> HTML attribute, to at least allow tabbing to it.<\/p>\n\n\n\nDemo forms<\/h2>\n