Hacker News Reader

Comment by wongarsu | Hacker News Reader

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)

View on HN

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.

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.)

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?

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…

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.

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.

> 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?

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.

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.

Reply on news.ycombinator.com