> What if you submit the form, but the request never arrives?

I think the proper way is to disable the button, then set the subsequent state of the button depending on the response from the server if any.

  submit => check button state and if enabled then => disable button => server response (or not, then timeout) => update button state (along with error message if any)

That flow is exactly what this article is telling you not to do. Basically the article said "don't do X, do Y instead", and GP said "ok, but if I don't do X, what if Z happens?" and your response is "the proper way to do it is X". If that's true, can you address the reasons the article says to not do X?

I think the salient point of the article was not to use the disable attribute and instead to use CSS to indicate a disabled state. As I understood the article, they were not against disabling the click per se, but against using the disabled attribute because of its effect on screen readers.

GP by contrast was suggesting allowing someone to press submit multiple times. These are not the same discussion as I see it. My response was more to address that, and was agnostic about whether the attribute or CSS disables the button.

As for using the disabled attribute, I agree with comments that it's not semantic to simulate `disabled` with CSS when we have a perfectly good disabled attribute, and it's the responsibility in this case of the screen readers to render this situation as it is meant to be understood. I'm open to reasonable disagreement here but I think the consensus is that the article is incorrect.

As for allowing multiple submissions, I think it's probably a good idea in general to program defensively against duplicate submissions and return a 409 when in doubt. But the user experience is improved by not allowing duplicate submissions on the front end for several reasons, among them that it's confusing. A POST is not idempotent, but allowing multiple submissions treats it that way.

The article seems to discourage disabled buttons for accessibility reasons also.

The article uses the wording “re-enable the button after the API responds”, but doesn’t elaborate on failure/timeout.

There’s other stuff you may want to do, like persist form data. Or if you go with the article’s recommendation of preserving the button, but make it inert, perhaps add some indication to what the request is doing.

There is nothing as a “sufficiently smart” website that altered the browser’s visual language of page loading progress. Meetup.com is doing this to me lately; some links I just don’t know if they’re broken, or my net is being slow, and I’m being impatient.