3 ms·

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

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.
- rendall 3y ago
  > 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)
  - feoren 3y ago
    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?
    - sshine 3y ago
      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.
    - 3y ago
danShumway 3y ago
Frustratingly, there is also an aria attribute for this, aria-disabled, that does not remove focus, and it should absolutely be added to any button implementing this strategy. If you're going to follow this article's advice, don't add a [data-submitting] attribute; use the aria-disabled as your selector. A custom data attribute does nothing for screenreaders or blind users who have no idea now whether a given button is disabled or not.

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.

rendall 3y ago
> 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)
- feoren 3y ago
  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?
  - sshine 3y ago
    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.
  - 3y ago

danShumway 3y ago

Frustratingly, there is also an aria attribute for this, aria-disabled, that does not remove focus, and it should absolutely be added to any button implementing this strategy. If you're going to follow this article's advice, don't add a [data-submitting] attribute; use the aria-disabled as your selector. A custom data attribute does nothing for screenreaders or blind users who have no idea now whether a given button is disabled or not.