Don't disable buttons

Original Article ↗ Hacker News Discussion ↗

Web developers are debating whether submit buttons should ever be disabled to prevent duplicate form submissions or invalid input, given how this interacts with accessibility tools and user expectations. Critics of the `disabled` attribute point out that it can break keyboard focus and confuse screen-reader users, arguing instead for custom “submitting” states, error messages, and ARIA attributes. Others counter that disabling unavailable actions is semantically correct, that servers must still guard against double submits, and that the real shortcomings lie in browser and assistive-technology behavior rather than in HTML’s design.

Ad vs content and scope

  • Some see the post as an implicit ad because it ends with “hire me,” others argue you can drop the last lines and it still stands as a useful, self‑contained article.
  • A few commenters think it omits important details (especially error handling after failed submissions).

HTML form behavior and double submission

  • Confusion over whether disabling a submit button blocks Enter-key submission; several replies cite the HTML spec: if there’s a disabled default submit button, implicit submission via Enter does not fire.
  • Many note that disabling the button alone doesn’t robustly prevent double submits; JS still has to guard against multiple in-flight requests.
  • Some say preventing double submit is fundamentally a backend concern; others argue for “belt and suspenders” with both frontend and backend protections.

Accessibility and focus issues

  • Core complaint: when a focused button becomes disabled, browsers move focus to the document root. Screen reader users then “lose their place,” which is disorienting.
  • Some call this a browser/screen-reader bug that should be fixed, not worked around by avoiding disabled.
  • Others argue that, given current behavior, avoiding disabled is pragmatic if you care about accessibility.

UX patterns: disabled vs enabled buttons

  • One camp: disabling non-functional buttons is semantically correct and common; users shouldn’t be able to trigger no-op actions.
  • Another camp: always allow clicking; on click, validate and show specific reasons why the action can’t proceed (“this field is invalid / missing”).
  • Several people criticize UIs where buttons are disabled with no clear indication how to enable them, or where partial-form validation plus disabled submit breaks password managers.
  • Suggested UX: show a loading state or spinner after submit, keep or manage focus explicitly, and present status and error messages.

Semantics, ARIA, and alternatives

  • Critics of the article say it really advocates “don’t use the disabled attribute; fake it with CSS and state,” which is semantically dubious and harms accessibility unless paired with aria-disabled and status messages (aria-live).
  • Some propose focusing a status element (“Submitting…”) rather than leaving focus on a disabled button.
  • Others insist semantics matter: use real disabled plus ARIA/status messaging, and improve tools rather than abandon native behavior.

Backend handling and idempotency

  • Multiple comments argue that duplicate submissions must be safely handled server-side (tokens, idempotency keys, UUIDs, rate limiting).
  • Some note the tension between HTTP semantics (POST not inherently idempotent) and practical needs like avoiding duplicate payments or comments.

Browser/platform design critiques

  • Repeated frustration that HTML forms and browser defaults make correct, accessible patterns hard.
  • Ideas floated: a singleSubmit or similar form attribute; better built-in “submitting” state; new attributes or revised disabled behavior that don’t drop focus.
  • General sentiment: the platform’s quirks force developers into fragile custom patterns for a basic task.