13 ms·

Don't disable buttons

200 points by damethos 3y ago

Night_Thastus 3y ago
Title is a bit broad for what the post actually talks about. There's plenty of good reasons to disable buttons, just not in this particular case.
- notfed 3y ago
  Also this sounds like an implementation detail with browsers.
anon23432343 3y ago
Can we add an "AD" tag in HN? Don't get me wrong but this really does not explain the full story and the post ends with basically: "If you really want to know pay for it". I don't have anything about paying for this information but at least say it is an AD for your agency.
- Leimi 3y ago
  Kinda harsh to see it that way. You could remove the last four 4 sentences of the post and don't see it as an ad at all. The post does actually explain the most important part and the guy just tells us we can hire him if we need help.
- thih9 3y ago
  What information exactly are you missing? The post lists why developers do it, why it’s bad, and what you can do instead - as promised. I don't think we should have an "ad" tag. Most "show hn" posts are basically ads for new products, and still very useful and very welcome. If you think a submission is inappropriate or dishonest, you can flag it and write your reasons in comments.
- g-b-r 3y ago
  It for sure makes you aware of a problem; I personally never thought about it, I imagine many other people didn't either
agos 3y ago
I was under the impression that a disabled submit button would also prevent the form by submitting on enter/return, is this not the case?
- anon23432343 3y ago
  No you can submit by pressing enter. for example if you have an login form and your focus is on the PW and you press enter then it still will be sent.
  - dbrgn 3y ago
    That depends on whether it's actually a classic HTML <form>, or whether it's just a collection of input fields submitted through JavaScript. And of course, if you disable the button, you could prevent duplicate form submission as well through the onsubmit event.
  - recursive 3y ago
    This is missing a detail. This only works if there is not a disabled `type=submit` element inside the form.
- chrismorgan 3y ago
  You are correct, and the original article is incorrect in this point (a pity, since the rest seems sound). Spec reference: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission https://html.spec.whatwg.org/multipage/form-control-infrastr... (It’s not written in the most obvious way as regards this detail, but it’s clearly there: if there is a default button, click on it, if you can—implied is: if you can’t, just do nothing; and if there isn’t a default button, try to just submit the form.)
huijzer 3y ago
Wouldn’t this cause problems if the first submit attempt fails? Then, the form won’t send again because it tried already?
- anon23432343 3y ago
  Its your job to remove that state if it fails and inform the user. This is just not written down in this post. Thats the part were you have to contact the writer.
  - alpaca128 3y ago
    > Thats the part were you have to contact the writer. Why? It's basic error handling. And the author linked to another explanation about the aria-live attribute for the user informing part.
    - chrismorgan 3y ago
      “Basic error handling” is distressingly rarely present, and when present, regularly broken. In general I do think it’s mildly irresponsible to not mention error handling at all and (taking what this article does) to show reenablement only via linear code flow that assumes success. But when it’s in an article about the problems of disabling submit buttons, then it’s even more perplexing.
magicalhippo 3y ago
We've been following that policy in our desktop application for a long time. It's almost always much better for the users that they get an error message saying why it's not possible to do X when they press the button, than not knowing why the button is disabled.
- wizofaus 3y ago
  "almost always" - agreed, but the specific case where your application has clearly gone into a temporary mode where no user interaction is permitted (other than perhaps "cancel") I would think was the exception. But simply adding the disabled attribute to the existing input controls probably isn't the best way to do it if it's an issue with screenreaders etc. Though it's not clear why such tools couldn't deal with it in a better fashion. I'd also say I'd have no issue with a button showing as disabled provided when you attempt to click it or hover over it, it tells you why it's not yet a permitted action. But again, might be an issue for accessibility etc.
- eviks 3y ago
  It's much better adding information to the UI explaining why the button is disabled rather than confusing the user to the point he's done an unnecessary action and got an error
pavlov 3y ago
The article is right, but it’s also an indictment of just how poorly designed HTML is for dynamic applications. Preventing double submission of data is a thoroughly basic feature for any UI library. It should be easy and obvious. But for HTML forms, the properly accessible solution shown here involves a non-intuitive combination of JavaScript, CSS and custom data attributes on an element.
- mattlondon 3y ago
  HTML wasn't designed for writing applications.
  - deleted 3y ago
    [deleted]
- kypro 3y ago
  HTML is just the language for describing the page content. It's not designed to be dynamic. A modern JS component library could have support for something like this. The author's suggestion of using a data attribute instead of adding a disabled class to the element and the styling of it is more of preference thing. That said, I don't really understand why there isn't something like a "singleSubmit" attribute you can add to a HTML form to automatically disable duplicate submissions. Handling double form submits is a frequent problem – you almost never want a form to be immediately resubmitable which HTML forms are.
  - pavlov 3y ago
    Your comment is a good example of the peculiar cognitive dissonance that surrounds HTML. The first reaction is always defensive, "HTML isn't designed for this!" — and two paragraphs later it's: "HTML should really do this though".
    - wzdd 3y ago
      I didn't see this as cognitive dissonance. It is "HTML and CSS are declarative. It would be good if there were a way to specify this requirement declaratively."
wongarsu 3y ago
Maybe pedantic, but OPs advise is actually "disable the button, but don't use the disable attribute to do it". Instead they store the disabled state in the form and set a CSS style to make the button look like a disabled button. Which makes that information unavailable to screen readers, but avoids screen readers jumping around the page because button loses focus when disabled. Also a useful note that disabling the button with the disabled attribute isn't enough to prevent people from submitting a form. Which is useful to remember, but not actually a justification for any of this (you can just check the disabled state of the button in your submit method)
- jwestbury 3y ago
  OP's advice is also incredibly frustrating if you've ever encountered a form where the Submit button seems to just do nothing. (Yes, you could pop a dialog which tells the user why it's doing nothing. In practice, that doesn't always occur.)
  - firejake308 3y ago
    I'm thinking a loading spinner would be the best compromise? Notifies the user that their input has been registered, and also explains why clicking again won't have any effect?
  - kspacewalk2 3y ago
    You may have missed this, towards the end of the post: >You can also style form elements to “appear” disabled using the [data-submitting] CSS selector…
    - karmakaze 3y ago
      So really all this whole post is saying is that the browser behaviour of an attribute-disabled button isn't optimal and that we can do better for accessibility, etc. Way to bury the lede.
- sshine 3y ago
  Another comment about what the author intends to fix: What if you submit the form, but the request never arrives? Then either a disabled or an unresponsive submit button are both jinxed: You may need to reload the page, possibly losing form data, in order to reset the ability to submit. Preventing fast double submits opens up a (small) can of worms wrt. managing state. You want to allow double submit in case of connection failure. You may even want to automate them, or add exponential back-off.
dbrgn 3y ago
If accessibility tools remove the focus from the disabled button and focus the document instead when a button is disabled, wouldn't this be a problem of the accessibility tool in the first place? Even just focussing the parent element would be a much much better idea than focusing the document. Making a button look disabled without actuall disabling it sounds like a semantically bad idea.
- alpaca128 3y ago
  As written in the article the "disabled" attribute doesn't disable submissions either, so it's mostly an appearance thing either way.
  - dbrgn 3y ago
    Of course the submission needs to be handled separately (if a <form> tag is being used). But that's not the point. The semantics for a disabled button are much clearer: You indicate that the button cannot be pressed (because it wouldn't actually do anything). Having a button that can be clicked, but that doesn't do anything, sounds like a wrong choice. Even worse is "making it look like it cannot be pressed by adding CSS rules". From what I know about accessibility, semantics are key. If the semantics are clear, then accessibility tools can optimize their flows accordingly. Using styling to convey semantics is a bad idea. If accessibility tools cannot deal well with certain situations, then those tools should be improved instead of making semantics worse.
    - deleted 3y ago
      [deleted]
    - creshal 3y ago
      There's two levels here: 1. The screenreader transforms the visual structure into something understandable for the human behind it 2. The human tries to make sense of it and maintain a mental model of what the screenreader is presenting to them Semantics are key for #1, but #2 can still lose track of what's happening on a complex form. For that, it helps if the human can keep trying, and fix whatever they missed on the next pass.
bradley13 3y ago
For me, the more common use case is to prevent users from making unnecessary mistakes. Only enable elements (like buttons) when all prerequisites are fulfilled. Simple example: if you require a user-name and password to login, then only enable the login button when that information is present. This improves the experience for the vast majority of users; it prevents them from overlooking something, and having to go back later and fix it. If this makes life difficult for a very few? That's probably a worthwhile tradeoff. Anyway, if you actually care about the people using screen readers, you should be offering them a separate experience anyway. One that doesn't involve JavaScript. Bet: the author of the article hasn't ever tried to use his fancy web-forms in Lynx.
- infotainment 3y ago
  > For me, the more common use case is to prevent users from making unnecessary mistakes. Only enable elements (like buttons) when all prerequisites are fulfilled. I’d argue this is actually worse UX, because in some cases (like a login form), it’s obvious, but in other cases, it might not be immediately clear to a user why the button is disabled. IMO it’s better UX to always enable the button, but provide clear messaging explaining 1) why the user couldn’t do the thing and 2) what needs to be fixed in order to do the thing
  - xigoi 3y ago
    Disable the button and give it a tooltip or some text above it saying why it's disabled. I've seen this pattern and liked it.
- ghusbands 3y ago
  > Anyway, if you actually care about the people using screen readers, you should be offering them a separate experience anyway. That's a very odd claim. Pretty much nobody does that, and segregating people is not generally a good idea. You need to bake accessibility into everything you do. Screen readers and javascript work well enough together.
FabHK 3y ago
Stupid question - couldn't (shouldn't) form submission be sort of idempotent? That is, if the same thing gets submitted again, drop it on the server side, rather than doing all sorts of fancy stuff on the client?
- Toutouxc 3y ago
  Should I not be able to send money to the same person twice in a row? Unless you add a single-use token to the form, your server doesn't know whether it was a misclick or a legitimate action. The client more or less knows.
  - omoikane 3y ago
    The form should indeed include single-use tokens to allow server-side filtering of duplicates. Related: https://en.wikipedia.org/wiki/Replay_attack https://en.wikipedia.org/wiki/Replay_attack
- Waterluvian 3y ago
  Yes it should be. But belt and suspenders. It’s crummy UX for it to happen in the first place. And an easy way to accidentally spam calls if someone’s cat sits on the enter key.
- SoftTalker 3y ago
  Thank you, I was scanning the replies looking for this. If preventing duplicate submissions is a concern, you must prevent it on the server side. You should also try to prevent it on the client for a better UX.
- recursive 3y ago
  Only sometimes. Whether it is in your case depends on the business rules of your application.
vasdae 3y ago
Allow me to hijack this thread to say something that is related: Do not disable buttons or checkboxes or whatever unless it's very obvious how to enable them! I have seen software applications that showed disabled form controls or menu entries depending on settings that were in other screens or even compile-time settings - that is unacceptable!
- jspash 3y ago
  Does anyone remember the "reset" button? I assume it still exists, but to be honest I have never found the need for it. But I do remember it being on many forms that you would encounter pre-2000.
  - lakomen 3y ago
    Reset buttons are for edit forms.
- city41 3y ago
  I was going to post this. Many times I've sat there trying to guess what the developer was thinking "maybe this will enable it? no... how about this?..." I can't even imagine what non-techy people do in these situations.
- deleted 3y ago
  [deleted]
Robdel12 3y ago
No, I 100% disagree. You just need to manage the focus yourself when you do disable the button.
- crazygringo 3y ago
  Yup. That seems like the easiest, most straightforward workaround for the bad browser behavior than anything the article suggests.
flappyeagle 3y ago
It’s weird to see so many UX articles on the front page of HN that are just wrong. Disabling buttons that are functionally no-ops is the semantically correct thing to do.
- nosefurhairdo 3y ago
  It's not a UX article, it's an accessibility article. Disabling the button can be confusing for users relying on screen readers, and if it's the only way the "submission pending" state is communicated to the user then it's plainly non-conforming with WCAG.
  - agloe_dreams 3y ago
    Seeing as most forms work this way...shouldn't the screen reader understand this? You are in a form, the button is the submit button. It went to disabled after form submit. Save that ref, fake the tab index so tabbing takes you to the next item, if the button becomes enabled again, highlight it. This feels like an easy win.
  - jeroenhd 3y ago
    The browsers and/or the screen readers are the problem here. Resetting focus to the document level doesn't make sense, and screen readers should just be able to read disabled buttons. The proposed solution (hacking together a pseudo-disabled button) will only lead to more ugly buttons that don't seem to do anything. Setting the transparency on a button does not make it look disabled, nor does it stop the click animation which would suggest the button is still activating something. If you're going to hack around silly browser bugs like these, add a loading spinner with ARIA description "submitting your form" and put it into focus. That way you can disable buttons all you like without resorting to weird workarounds.
rickstanley 3y ago
If the problem is shifting focus to the document, is it not better to: before disabling the button, with the attribute, create an element that contains information about the action in progress and focus on this element via `element.focus();`, and then add the "disabled" attribute?
- g-b-r 3y ago
  I agree, you're avoiding disabling the button to cater for screen readers, at that point go one step further and move to an (invisible?) "Form sent" element ..
viggity 3y ago
furthermore, on any app, don't disable a button when an action isn't available. you can still mark it as disabled via color, but if someone clicks on it, you should show them a message WHY that action isn't available. "Sorry, you haven't filled in your phone number", etc.
thesuitonym 3y ago
Similarly, don't disable submit buttons so you can wait for me to type something. Especially for login forms, many password managers don't type usernames and passwords, but some login forms wait for you to type something before they'll allow you to submit.
- pimlottc 3y ago
  Furthermore, these forms often don't notice when your password manager has filled in the fields for you, so you have to go back and make a meaningless edit (e.g. add and then remove a character) in order to enable to the submit button.
  - Semaphor 3y ago
    Like ebay
  - sefrost 3y ago
    Every time I have to do something like that I wonder how people like my parents manage to use computers.
    - extraduder_ire 3y ago
      I assume they're in the group of users these sorts of interfaces are designed for. Hunt and peck typing, will dutifully following the flow chart of interaction across multiple pages and assume they are wrong when they are made to start again when they click a wrong button, and not being annoyed when the "you are being logged out in 30 seconds. Cancel?" message pops up. Or, they are used to finding someone who's "good with computers" to assist. That alone probably hides so much garbage UX from being known to developers.
    - beambot 3y ago
      My parents used punch cards and DIP switches to control their first computers. They think modern computers are basically magic by comparison...
    - 3y ago
hk1337 3y ago
It's an excellent point but perhaps the solution still doesn't solve the problems. Like, it fixes the problem for accessibility but then creates or leaves problems for user experience.
- nosefurhairdo 3y ago
  For sighted users, show indeterminate progress element while form is submitting. For sight-impaired users, use aria live region for accessible status messages (as noted in article). For more info on status messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html https://www.w3.org/WAI/WCAG22/Understanding/status-messages.... Were there any other UX concerns you had with this pattern?
  - hk1337 3y ago
    I don't know of any. I liked that OP pointed it out also the glaring hole that sighted users (or really any user) could still move up to a form element and hit enter to resubmit, thus bypassing that the submit button is disabled.
seanwilson 3y ago
Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? It's clearly difficult if there's so many options and this generates so much discussion. It shouldn't be this hard to get a basic UI pattern right (submitting a form once with progress updates). If it's even a little hard, it's inevitable 90% of sites will get it wrong. There's just too much stuff for devs to realistically stay on top of to blame them. Related: the `inert` attribute has good support now for preventing users from editing/interacting with forms that are currently being submitted so you don't have to mess with overriding input events (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inert https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...). You'll have to add it manually when the form is submitted though, remove it if the submission fails, and use something like aria-live to give progress updates (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...). You'll also need to manually test all your custom forms like this work on actual screen readers (they have inconsistent behaviour, similar to cross-browser bugs), as well as edge cases like resubmitting after a failure, when the network request fails with error feedback, and when the network request fails from a time out. Not easy.
- ASalazarMX 3y ago
  > Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? My pet peevee is how browsers; and later smartphones; normalized that interactive elements can reflow/reorganize all the time. Now, things like joining a specific WiFi, or mirropring to a specific TV, can become a game of chance if you don't let the UI settle a bit. We had this problem more or less solved before.
  - jbverschoor 3y ago
    HTML is a document, as in hyperlinked rich text, format / "language". People abused HTTP/HTML as an application delivery platform. Now we finally have some better positioning / sizing for applications. It's the same as QWERTY... Not the best way, but got popular, and now we're stuck with it, trying to patch everything for the last 25 years.
danbruc 3y ago
Disagree. If it is currently invalid to click the button, disable it, that is what it is for. Disabled buttons should be focusable, that resolves the issue with disabling the focused button in response to a click. How you achieve this in any given environment is a different issue, if the out of the box disabled functionality does not work properly, you will have to find workarounds.
some1else 3y ago
Do disable buttons. You can keep an isSubmitting value around for tracking form state. This does not forbid using the disabled property.
extraduder_ire 3y ago
Is there a blogpost out there like "X things programmers don't understand about HTML forms"? In the same vain as the ones for names, character encoding, etc... I'm sure there'd be a few humdingers in there.
deleted 3y ago
[deleted]
jolt42 3y ago
Can we also talk about aggressively deleting form fields? Forgot password? Let me forget the email you just typed in when trying to login. Guessed the wrong password? I'll erase that field for you.
danShumway 3y ago
The article doesn't mention this, but if you are going to build your own disabled state, at the very least include an aria-disabled attribute on your button. See Mozilla docs on the subject, which mention this exact same scenario: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... Using pure-CSS and data-attributes without additional indicators doesn't help low-vision users; the only thing they'll be able to tell is that click doesn't work on some of your buttons, they won't be able to see the CSS or non-semantic attributes that say the button is disabled. If you're getting rid of browser semantics, you need to include the relevant aria semantics to compensate.
al_be_back 3y ago
For me the disabled button on a partially-valid Form say, is a metaphor-overload. Whilst a physical button may be disabled to indicate being functional-but-not-ready, in software one doesn't have to show/display them until they are ready for action. If the Form is partially valid, show a Message instead of a Button, then when it is valid, pop the Action button clearly on display. Personally I like to leave the button enabled, check the Action can be performed (form valid etc), and notify the User of errors, progress etc. It's better to communicate with the User exactly, than imply messages - it's a form, not a puzzle or an opportunity to play physical jokes on the User (gotcha, can't press this!).
beders 3y ago
The crux with a disabled button is discoverability: What is the user supposed to do to enable it?
amelius 3y ago
With this approach, an exception thrown while submitting may break the submit button. This is worse than what we started with!
andrewmcwatters 3y ago
Amazon, of all places, had this defect in their login flow for the longest time which was only recently fixed. It was so bad that when you were waiting for an SMS code, after you received it and autofilled it in iOS, their website and app would automatically submit the input, and so hitting submit on your keyboard would cause the backend to reprocess the code a second time, invalidating your login. It was obvious someone slapped the implementation together and it was so embarrassing. Yet, I’m still nonplussed that we keep screwing up forms.
yuters 3y ago
It would be weird to avoid the only reason I have to use this button attribute. I thought the disabled state only existed to fix this problem. I can't find any other use that wouldn't end up being a complete UX mistake.
lakomen 3y ago
BS I say. In a JS framework frontend I will disable the button on submit, so the form can't be submitted twice, because accidental double clicks happen. I will enable it after at most 6 seconds or if the response is an error response.
iteratethis 3y ago
So you have focus on a button, which then becomes disabled, this throws focus back at the document level. That sounds like a browser bug to me. It's absurd behavior. The focus change is as unhelpful as is humanly possible. It's not what the developer intended, it's not what anyone possibly would intend, so why is it the default behavior? Same for "implementing an ARIA live region" How about no? Developers are supposed to piece together hundreds of obscure articles to figure out the right way to build an accessible form. Most won't, but if they do, they're still not confident about its implementation. How about after 30 years the web platform provides some elements that actually do something, with sane defaults instead of millions of developers being puzzled what to do for even the most basic of tasks?
steve_adams_86 3y ago
I agree with some of the perceived issues, but not entirely with the solution. I think this is what state machines are for. The disabled attribute is in a sense part of the button's own state-oriented behaviours, but as mentioned it isn't really sufficient to prevent other interactions or submissions. You can prevent form submissions and/or ignore them by orchestrating form UI and interactions within a state machine, though. It sounds complex, but it's an abstraction that can be easily reused across forms, and it's not an expensive abstraction. If you're using JS, it's a trivial addition that can provide easily tested, robust, reliable form behaviours that respect your users and your business logic. I've wondered many times why something like <form id="my-form disabled> isn't possible.
bluSCALE4 3y ago
Disabling a button is not up for argument. You are entitled an opinion but you are wrong. As mentioned in the article, it becomes invisible for screen readers so, no, hard stop on its usage. From a usability standpoint, an available button gives you the opportunity to validate a users field, shortcut someone to that field and if you use form properly, allow the user to go on to the next invalid field with the enter key.
DecoPerson 3y ago
Good advice! I go one step further with buttons in my own React UI library, and I wish all UI libraries did the same: When a button is “disabled”, it should show why either on hover or on click. It’s a common frustration in software, especially complex ones like Adobe Photoshop or Autodesk Fusion 360, where a button is disabled and you cannot figure out why. For example: you can’t fill because it’s a “smart layer” and you need to rasterise it. Or you can’t “join” because both CAD bodies are fixed. The programs KNOW why the button is disabled — otherwise how would it know to disable the button! So show the user why! This alone would save countless person-hours and reduce a lot of frustration.
ivanjermakov 3y ago
This sounds like a browser problem to me. Disabled button should be reported by screen reader as a disabled button, not just magically disappear.
hawkesnest 3y ago
Here's a similar take from Joel Spolsky: A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used. Don’t do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work. Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.
vlucas 3y ago
> If the button is the current item in focus when you add the disabled attribute (for example, if someone just pressed it to submit the form), the element actually loses focus, which shifts to the document element. > For a screen reader user, this is particularly jarring, as now you’re in a totally different place on the page. This just feels like an argument to abandon a very useful, well understood, and built-in tool (disabling to preventing double form submission) in order to make things better for a small subset of users of a particular tool. Why can't this just be the problem of screen readers? Why is the "solution" to not use or remove a widely used and well understood web standard?

200 points by damethos 3y ago

Title is a bit broad for what the post actually talks about. There's plenty of good reasons to disable buttons, just not in this particular case.

notfed 3y ago
Also this sounds like an implementation detail with browsers.

anon23432343 3y ago

Can we add an "AD" tag in HN? Don't get me wrong but this really does not explain the full story and the post ends with basically: "If you really want to know pay for it". I don't have anything about paying for this information but at least say it is an AD for your agency.

Leimi 3y ago
Kinda harsh to see it that way. You could remove the last four 4 sentences of the post and don't see it as an ad at all. The post does actually explain the most important part and the guy just tells us we can hire him if we need help.
thih9 3y ago
What information exactly are you missing? The post lists why developers do it, why it’s bad, and what you can do instead - as promised. I don't think we should have an "ad" tag. Most "show hn" posts are basically ads for new products, and still very useful and very welcome. If you think a submission is inappropriate or dishonest, you can flag it and write your reasons in comments.
g-b-r 3y ago
It for sure makes you aware of a problem; I personally never thought about it, I imagine many other people didn't either

agos 3y ago

I was under the impression that a disabled submit button would also prevent the form by submitting on enter/return, is this not the case?

anon23432343 3y ago
No you can submit by pressing enter. for example if you have an login form and your focus is on the PW and you press enter then it still will be sent.
- dbrgn 3y ago
  That depends on whether it's actually a classic HTML <form>, or whether it's just a collection of input fields submitted through JavaScript. And of course, if you disable the button, you could prevent duplicate form submission as well through the onsubmit event.
- recursive 3y ago
  This is missing a detail. This only works if there is not a disabled `type=submit` element inside the form.
chrismorgan 3y ago
You are correct, and the original article is incorrect in this point (a pity, since the rest seems sound). Spec reference: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission https://html.spec.whatwg.org/multipage/form-control-infrastr... (It’s not written in the most obvious way as regards this detail, but it’s clearly there: if there is a default button, click on it, if you can—implied is: if you can’t, just do nothing; and if there isn’t a default button, try to just submit the form.)

huijzer 3y ago

Wouldn’t this cause problems if the first submit attempt fails? Then, the form won’t send again because it tried already?

anon23432343 3y ago
Its your job to remove that state if it fails and inform the user. This is just not written down in this post. Thats the part were you have to contact the writer.
- alpaca128 3y ago
  > Thats the part were you have to contact the writer. Why? It's basic error handling. And the author linked to another explanation about the aria-live attribute for the user informing part.
  - chrismorgan 3y ago
    “Basic error handling” is distressingly rarely present, and when present, regularly broken. In general I do think it’s mildly irresponsible to not mention error handling at all and (taking what this article does) to show reenablement only via linear code flow that assumes success. But when it’s in an article about the problems of disabling submit buttons, then it’s even more perplexing.

magicalhippo 3y ago

We've been following that policy in our desktop application for a long time. It's almost always much better for the users that they get an error message saying why it's not possible to do X when they press the button, than not knowing why the button is disabled.

wizofaus 3y ago
"almost always" - agreed, but the specific case where your application has clearly gone into a temporary mode where no user interaction is permitted (other than perhaps "cancel") I would think was the exception. But simply adding the disabled attribute to the existing input controls probably isn't the best way to do it if it's an issue with screenreaders etc. Though it's not clear why such tools couldn't deal with it in a better fashion. I'd also say I'd have no issue with a button showing as disabled provided when you attempt to click it or hover over it, it tells you why it's not yet a permitted action. But again, might be an issue for accessibility etc.
eviks 3y ago
It's much better adding information to the UI explaining why the button is disabled rather than confusing the user to the point he's done an unnecessary action and got an error

pavlov 3y ago

The article is right, but it’s also an indictment of just how poorly designed HTML is for dynamic applications. Preventing double submission of data is a thoroughly basic feature for any UI library. It should be easy and obvious. But for HTML forms, the properly accessible solution shown here involves a non-intuitive combination of JavaScript, CSS and custom data attributes on an element.

mattlondon 3y ago
HTML wasn't designed for writing applications.
- deleted 3y ago
  [deleted]
kypro 3y ago
HTML is just the language for describing the page content. It's not designed to be dynamic. A modern JS component library could have support for something like this. The author's suggestion of using a data attribute instead of adding a disabled class to the element and the styling of it is more of preference thing. That said, I don't really understand why there isn't something like a "singleSubmit" attribute you can add to a HTML form to automatically disable duplicate submissions. Handling double form submits is a frequent problem – you almost never want a form to be immediately resubmitable which HTML forms are.
- pavlov 3y ago
  Your comment is a good example of the peculiar cognitive dissonance that surrounds HTML. The first reaction is always defensive, "HTML isn't designed for this!" — and two paragraphs later it's: "HTML should really do this though".
  - wzdd 3y ago
    I didn't see this as cognitive dissonance. It is "HTML and CSS are declarative. It would be good if there were a way to specify this requirement declaratively."

wongarsu 3y ago

Maybe pedantic, but OPs advise is actually "disable the button, but don't use the disable attribute to do it". Instead they store the disabled state in the form and set a CSS style to make the button look like a disabled button. Which makes that information unavailable to screen readers, but avoids screen readers jumping around the page because button loses focus when disabled. Also a useful note that disabling the button with the disabled attribute isn't enough to prevent people from submitting a form. Which is useful to remember, but not actually a justification for any of this (you can just check the disabled state of the button in your submit method)

jwestbury 3y ago
OP's advice is also incredibly frustrating if you've ever encountered a form where the Submit button seems to just do nothing. (Yes, you could pop a dialog which tells the user why it's doing nothing. In practice, that doesn't always occur.)
- firejake308 3y ago
  I'm thinking a loading spinner would be the best compromise? Notifies the user that their input has been registered, and also explains why clicking again won't have any effect?
- kspacewalk2 3y ago
  You may have missed this, towards the end of the post: >You can also style form elements to “appear” disabled using the [data-submitting] CSS selector…
  - karmakaze 3y ago
    So really all this whole post is saying is that the browser behaviour of an attribute-disabled button isn't optimal and that we can do better for accessibility, etc. Way to bury the lede.
sshine 3y ago
Another comment about what the author intends to fix: What if you submit the form, but the request never arrives? Then either a disabled or an unresponsive submit button are both jinxed: You may need to reload the page, possibly losing form data, in order to reset the ability to submit. Preventing fast double submits opens up a (small) can of worms wrt. managing state. You want to allow double submit in case of connection failure. You may even want to automate them, or add exponential back-off.

dbrgn 3y ago

If accessibility tools remove the focus from the disabled button and focus the document instead when a button is disabled, wouldn't this be a problem of the accessibility tool in the first place? Even just focussing the parent element would be a much much better idea than focusing the document. Making a button look disabled without actuall disabling it sounds like a semantically bad idea.

alpaca128 3y ago
As written in the article the "disabled" attribute doesn't disable submissions either, so it's mostly an appearance thing either way.
- dbrgn 3y ago
  Of course the submission needs to be handled separately (if a <form> tag is being used). But that's not the point. The semantics for a disabled button are much clearer: You indicate that the button cannot be pressed (because it wouldn't actually do anything). Having a button that can be clicked, but that doesn't do anything, sounds like a wrong choice. Even worse is "making it look like it cannot be pressed by adding CSS rules". From what I know about accessibility, semantics are key. If the semantics are clear, then accessibility tools can optimize their flows accordingly. Using styling to convey semantics is a bad idea. If accessibility tools cannot deal well with certain situations, then those tools should be improved instead of making semantics worse.
  - deleted 3y ago
    [deleted]
  - creshal 3y ago
    There's two levels here: 1. The screenreader transforms the visual structure into something understandable for the human behind it 2. The human tries to make sense of it and maintain a mental model of what the screenreader is presenting to them Semantics are key for #1, but #2 can still lose track of what's happening on a complex form. For that, it helps if the human can keep trying, and fix whatever they missed on the next pass.

bradley13 3y ago

For me, the more common use case is to prevent users from making unnecessary mistakes. Only enable elements (like buttons) when all prerequisites are fulfilled. Simple example: if you require a user-name and password to login, then only enable the login button when that information is present. This improves the experience for the vast majority of users; it prevents them from overlooking something, and having to go back later and fix it. If this makes life difficult for a very few? That's probably a worthwhile tradeoff. Anyway, if you actually care about the people using screen readers, you should be offering them a separate experience anyway. One that doesn't involve JavaScript. Bet: the author of the article hasn't ever tried to use his fancy web-forms in Lynx.

infotainment 3y ago
> For me, the more common use case is to prevent users from making unnecessary mistakes. Only enable elements (like buttons) when all prerequisites are fulfilled. I’d argue this is actually worse UX, because in some cases (like a login form), it’s obvious, but in other cases, it might not be immediately clear to a user why the button is disabled. IMO it’s better UX to always enable the button, but provide clear messaging explaining 1) why the user couldn’t do the thing and 2) what needs to be fixed in order to do the thing
- xigoi 3y ago
  Disable the button and give it a tooltip or some text above it saying why it's disabled. I've seen this pattern and liked it.
ghusbands 3y ago
> Anyway, if you actually care about the people using screen readers, you should be offering them a separate experience anyway. That's a very odd claim. Pretty much nobody does that, and segregating people is not generally a good idea. You need to bake accessibility into everything you do. Screen readers and javascript work well enough together.

FabHK 3y ago

Stupid question - couldn't (shouldn't) form submission be sort of idempotent? That is, if the same thing gets submitted again, drop it on the server side, rather than doing all sorts of fancy stuff on the client?

Toutouxc 3y ago
Should I not be able to send money to the same person twice in a row? Unless you add a single-use token to the form, your server doesn't know whether it was a misclick or a legitimate action. The client more or less knows.
- omoikane 3y ago
  The form should indeed include single-use tokens to allow server-side filtering of duplicates. Related: https://en.wikipedia.org/wiki/Replay_attack https://en.wikipedia.org/wiki/Replay_attack
Waterluvian 3y ago
Yes it should be. But belt and suspenders. It’s crummy UX for it to happen in the first place. And an easy way to accidentally spam calls if someone’s cat sits on the enter key.
SoftTalker 3y ago
Thank you, I was scanning the replies looking for this. If preventing duplicate submissions is a concern, you must prevent it on the server side. You should also try to prevent it on the client for a better UX.
recursive 3y ago
Only sometimes. Whether it is in your case depends on the business rules of your application.

vasdae 3y ago

Allow me to hijack this thread to say something that is related: Do not disable buttons or checkboxes or whatever unless it's very obvious how to enable them! I have seen software applications that showed disabled form controls or menu entries depending on settings that were in other screens or even compile-time settings - that is unacceptable!

jspash 3y ago
Does anyone remember the "reset" button? I assume it still exists, but to be honest I have never found the need for it. But I do remember it being on many forms that you would encounter pre-2000.
- lakomen 3y ago
  Reset buttons are for edit forms.
city41 3y ago
I was going to post this. Many times I've sat there trying to guess what the developer was thinking "maybe this will enable it? no... how about this?..." I can't even imagine what non-techy people do in these situations.
deleted 3y ago
[deleted]

Robdel12 3y ago

No, I 100% disagree. You just need to manage the focus yourself when you do disable the button.

crazygringo 3y ago
Yup. That seems like the easiest, most straightforward workaround for the bad browser behavior than anything the article suggests.

flappyeagle 3y ago

It’s weird to see so many UX articles on the front page of HN that are just wrong. Disabling buttons that are functionally no-ops is the semantically correct thing to do.

nosefurhairdo 3y ago
It's not a UX article, it's an accessibility article. Disabling the button can be confusing for users relying on screen readers, and if it's the only way the "submission pending" state is communicated to the user then it's plainly non-conforming with WCAG.
- agloe_dreams 3y ago
  Seeing as most forms work this way...shouldn't the screen reader understand this? You are in a form, the button is the submit button. It went to disabled after form submit. Save that ref, fake the tab index so tabbing takes you to the next item, if the button becomes enabled again, highlight it. This feels like an easy win.
- jeroenhd 3y ago
  The browsers and/or the screen readers are the problem here. Resetting focus to the document level doesn't make sense, and screen readers should just be able to read disabled buttons. The proposed solution (hacking together a pseudo-disabled button) will only lead to more ugly buttons that don't seem to do anything. Setting the transparency on a button does not make it look disabled, nor does it stop the click animation which would suggest the button is still activating something. If you're going to hack around silly browser bugs like these, add a loading spinner with ARIA description "submitting your form" and put it into focus. That way you can disable buttons all you like without resorting to weird workarounds.

rickstanley 3y ago

If the problem is shifting focus to the document, is it not better to: before disabling the button, with the attribute, create an element that contains information about the action in progress and focus on this element via `element.focus();`, and then add the "disabled" attribute?

g-b-r 3y ago
I agree, you're avoiding disabling the button to cater for screen readers, at that point go one step further and move to an (invisible?) "Form sent" element ..

viggity 3y ago

furthermore, on any app, don't disable a button when an action isn't available. you can still mark it as disabled via color, but if someone clicks on it, you should show them a message WHY that action isn't available. "Sorry, you haven't filled in your phone number", etc.

thesuitonym 3y ago

Similarly, don't disable submit buttons so you can wait for me to type something. Especially for login forms, many password managers don't type usernames and passwords, but some login forms wait for you to type something before they'll allow you to submit.

pimlottc 3y ago
Furthermore, these forms often don't notice when your password manager has filled in the fields for you, so you have to go back and make a meaningless edit (e.g. add and then remove a character) in order to enable to the submit button.
- Semaphor 3y ago
  Like ebay
- sefrost 3y ago
  Every time I have to do something like that I wonder how people like my parents manage to use computers.
  - extraduder_ire 3y ago
    I assume they're in the group of users these sorts of interfaces are designed for. Hunt and peck typing, will dutifully following the flow chart of interaction across multiple pages and assume they are wrong when they are made to start again when they click a wrong button, and not being annoyed when the "you are being logged out in 30 seconds. Cancel?" message pops up. Or, they are used to finding someone who's "good with computers" to assist. That alone probably hides so much garbage UX from being known to developers.
  - beambot 3y ago
    My parents used punch cards and DIP switches to control their first computers. They think modern computers are basically magic by comparison...
  - 3y ago

hk1337 3y ago

It's an excellent point but perhaps the solution still doesn't solve the problems. Like, it fixes the problem for accessibility but then creates or leaves problems for user experience.

nosefurhairdo 3y ago
For sighted users, show indeterminate progress element while form is submitting. For sight-impaired users, use aria live region for accessible status messages (as noted in article). For more info on status messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html https://www.w3.org/WAI/WCAG22/Understanding/status-messages.... Were there any other UX concerns you had with this pattern?
- hk1337 3y ago
  I don't know of any. I liked that OP pointed it out also the glaring hole that sighted users (or really any user) could still move up to a form element and hit enter to resubmit, thus bypassing that the submit button is disabled.

seanwilson 3y ago

Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? It's clearly difficult if there's so many options and this generates so much discussion. It shouldn't be this hard to get a basic UI pattern right (submitting a form once with progress updates). If it's even a little hard, it's inevitable 90% of sites will get it wrong. There's just too much stuff for devs to realistically stay on top of to blame them. Related: the `inert` attribute has good support now for preventing users from editing/interacting with forms that are currently being submitted so you don't have to mess with overriding input events (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inert https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...). You'll have to add it manually when the form is submitted though, remove it if the submission fails, and use something like aria-live to give progress updates (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...). You'll also need to manually test all your custom forms like this work on actual screen readers (they have inconsistent behaviour, similar to cross-browser bugs), as well as edge cases like resubmitting after a failure, when the network request fails with error feedback, and when the network request fails from a time out. Not easy.

ASalazarMX 3y ago
> Will browsers ever catch up here so that the right way to do it is the default way? Or at least one of the easiest ways? My pet peevee is how browsers; and later smartphones; normalized that interactive elements can reflow/reorganize all the time. Now, things like joining a specific WiFi, or mirropring to a specific TV, can become a game of chance if you don't let the UI settle a bit. We had this problem more or less solved before.
- jbverschoor 3y ago
  HTML is a document, as in hyperlinked rich text, format / "language". People abused HTTP/HTML as an application delivery platform. Now we finally have some better positioning / sizing for applications. It's the same as QWERTY... Not the best way, but got popular, and now we're stuck with it, trying to patch everything for the last 25 years.

danbruc 3y ago

Disagree. If it is currently invalid to click the button, disable it, that is what it is for. Disabled buttons should be focusable, that resolves the issue with disabling the focused button in response to a click. How you achieve this in any given environment is a different issue, if the out of the box disabled functionality does not work properly, you will have to find workarounds.

some1else 3y ago

Do disable buttons. You can keep an isSubmitting value around for tracking form state. This does not forbid using the disabled property.

extraduder_ire 3y ago

Is there a blogpost out there like "X things programmers don't understand about HTML forms"? In the same vain as the ones for names, character encoding, etc... I'm sure there'd be a few humdingers in there.

deleted 3y ago

[deleted]

jolt42 3y ago

Can we also talk about aggressively deleting form fields? Forgot password? Let me forget the email you just typed in when trying to login. Guessed the wrong password? I'll erase that field for you.

danShumway 3y ago

The article doesn't mention this, but if you are going to build your own disabled state, at the very least include an aria-disabled attribute on your button. See Mozilla docs on the subject, which mention this exact same scenario: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... Using pure-CSS and data-attributes without additional indicators doesn't help low-vision users; the only thing they'll be able to tell is that click doesn't work on some of your buttons, they won't be able to see the CSS or non-semantic attributes that say the button is disabled. If you're getting rid of browser semantics, you need to include the relevant aria semantics to compensate.

al_be_back 3y ago

For me the disabled button on a partially-valid Form say, is a metaphor-overload. Whilst a physical button may be disabled to indicate being functional-but-not-ready, in software one doesn't have to show/display them until they are ready for action. If the Form is partially valid, show a Message instead of a Button, then when it is valid, pop the Action button clearly on display. Personally I like to leave the button enabled, check the Action can be performed (form valid etc), and notify the User of errors, progress etc. It's better to communicate with the User exactly, than imply messages - it's a form, not a puzzle or an opportunity to play physical jokes on the User (gotcha, can't press this!).

beders 3y ago

The crux with a disabled button is discoverability: What is the user supposed to do to enable it?

amelius 3y ago

With this approach, an exception thrown while submitting may break the submit button. This is worse than what we started with!

andrewmcwatters 3y ago

Amazon, of all places, had this defect in their login flow for the longest time which was only recently fixed. It was so bad that when you were waiting for an SMS code, after you received it and autofilled it in iOS, their website and app would automatically submit the input, and so hitting submit on your keyboard would cause the backend to reprocess the code a second time, invalidating your login. It was obvious someone slapped the implementation together and it was so embarrassing. Yet, I’m still nonplussed that we keep screwing up forms.

yuters 3y ago

It would be weird to avoid the only reason I have to use this button attribute. I thought the disabled state only existed to fix this problem. I can't find any other use that wouldn't end up being a complete UX mistake.

lakomen 3y ago

BS I say. In a JS framework frontend I will disable the button on submit, so the form can't be submitted twice, because accidental double clicks happen. I will enable it after at most 6 seconds or if the response is an error response.

iteratethis 3y ago

So you have focus on a button, which then becomes disabled, this throws focus back at the document level. That sounds like a browser bug to me. It's absurd behavior. The focus change is as unhelpful as is humanly possible. It's not what the developer intended, it's not what anyone possibly would intend, so why is it the default behavior? Same for "implementing an ARIA live region" How about no? Developers are supposed to piece together hundreds of obscure articles to figure out the right way to build an accessible form. Most won't, but if they do, they're still not confident about its implementation. How about after 30 years the web platform provides some elements that actually do something, with sane defaults instead of millions of developers being puzzled what to do for even the most basic of tasks?

steve_adams_86 3y ago

I agree with some of the perceived issues, but not entirely with the solution. I think this is what state machines are for. The disabled attribute is in a sense part of the button's own state-oriented behaviours, but as mentioned it isn't really sufficient to prevent other interactions or submissions. You can prevent form submissions and/or ignore them by orchestrating form UI and interactions within a state machine, though. It sounds complex, but it's an abstraction that can be easily reused across forms, and it's not an expensive abstraction. If you're using JS, it's a trivial addition that can provide easily tested, robust, reliable form behaviours that respect your users and your business logic. I've wondered many times why something like <form id="my-form disabled> isn't possible.

bluSCALE4 3y ago

Disabling a button is not up for argument. You are entitled an opinion but you are wrong. As mentioned in the article, it becomes invisible for screen readers so, no, hard stop on its usage. From a usability standpoint, an available button gives you the opportunity to validate a users field, shortcut someone to that field and if you use form properly, allow the user to go on to the next invalid field with the enter key.

DecoPerson 3y ago

Good advice! I go one step further with buttons in my own React UI library, and I wish all UI libraries did the same: When a button is “disabled”, it should show why either on hover or on click. It’s a common frustration in software, especially complex ones like Adobe Photoshop or Autodesk Fusion 360, where a button is disabled and you cannot figure out why. For example: you can’t fill because it’s a “smart layer” and you need to rasterise it. Or you can’t “join” because both CAD bodies are fixed. The programs KNOW why the button is disabled — otherwise how would it know to disable the button! So show the user why! This alone would save countless person-hours and reduce a lot of frustration.

ivanjermakov 3y ago

This sounds like a browser problem to me. Disabled button should be reported by screen reader as a disabled button, not just magically disappear.

hawkesnest 3y ago

Here's a similar take from Joel Spolsky: A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used. Don’t do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work. Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.

vlucas 3y ago

> If the button is the current item in focus when you add the disabled attribute (for example, if someone just pressed it to submit the form), the element actually loses focus, which shifts to the document element. > For a screen reader user, this is particularly jarring, as now you’re in a totally different place on the page. This just feels like an argument to abandon a very useful, well understood, and built-in tool (disabling to preventing double form submission) in order to make things better for a small subset of users of a particular tool. Why can't this just be the problem of screen readers? Why is the "solution" to not use or remove a widely used and well understood web standard?