Why a Semantic Button Beats a Styled Div

Developers frequently reach for a <div> when they need a clickable UI element. It is a common pattern, but inspecting the code often reveals a missed opportunity: the semantic <button> element exists for exactly this purpose.

Sticking with a <div> usually stems from a styling concern—buttons come with user-agent styles that feel like they need to be overridden, while a <div> arrives with no opinions about appearance. But resetting a button’s look takes only a single CSS rule. After that, the same class can style a <button> exactly like a <div>.

What DevTools Reveals

The developer tools in modern browsers expose the accessibility tree and computed semantics of any element. Inspecting both approaches demonstrates that the difference is not just visual:

  • The <button> is exposed with a button role, while the <div> defaults to a generic role.
  • The <button> receives an accessible label directly from its content.
  • The <button> is focusable and supports click events out of the box.

These are the baseline behaviors that must be manually recreated when a <div> is used instead.

The Hidden Cost of a Div

Re-implementing the built-in behavior of a button for a <div> involves several discrete steps:

  • Tab focus is not included. Browsers do not recognize a <div> as interactive. Adding role="button" only changes how assistive technology announces the element—it doesn’t change browser behavior. A tabindex must be added manually.
  • Keyboard activation is missing. Even with focus, a <div> won’t respond to the Space or Return keys. JavaScript is required to wire up that behavior.
  • The keys are not interchangeable. The Space and Return keys trigger different actions in the keyboard event model, so handling both usually means attaching separate listeners.
  • A disabled state requires custom logic. Native buttons support the disabled attribute, which handles focus and interaction states automatically. A <div> would need additional JavaScript to check for a data attribute and simulate that state.

The role="button" workaround is tempting but incomplete. It ensures a screen reader will announce the element as a button, but it contributes none of the interaction semantics that complete the user experience. No amount of CSS will change what the element fundamentally is.

Talking Points You Can Actually Use

“Semantics matter for accessibility” is true, but vague. The concrete benefits come down to the specifics:

  • Keyboard focus and interaction are native, not simulated.
  • Assistive technology gets accurate roles and labels without extra markup.
  • State changes, like disabling, are handled by the browser through a single attribute.

Each of those points overrides the perceived styling advantage of a <div>. The one-line CSS reset nullifies the effort argument entirely. Buttons are not just the recommended choice—they are also the pragmatic one.