Few topics in front-end development get as much attention as the difference between buttons and links. It has been covered extensively, including in our own guides, yet the mistake keeps showing up in production code. The rule itself is simple enough to memorize:

  • Navigating to another URL? Use a link: <a href="">.
  • Triggering on-page interactivity? Use a button: <button>.
  • Anything else is a deliberate deviation that you should be able to justify.

Eric Eggert recently made a compelling case for why this distinction matters beyond mere semantics. A keyboard whose e key only worked 90% of the time would be infuriating. The same principle applies to user interfaces: relying on the correct elements builds trust, letting users navigate content and applications with ease. Using the right elements means supporting your users.

Why Everything Else Falls Short

Manuel Matuzović's Button Cheat Sheet takes a humorous but pointed approach to demonstrating that virtually nothing performs as well as a native <button>. The cheat sheet links to Marcy Sutton's The Links vs. Buttons Showdown, a video that frames the two elements as competitors in a mock battle—one triggered by the space bar, the other by the enter key. The tone may be playful, but the underlying message about accessibility is serious: getting this wrong undermines keyboard support, screen reader behavior, and overall usability.

It is telling how much effort continues to go into spreading what should be foundational knowledge. The persistence of the problem suggests that even well-documented best practices require constant reinforcement before they become instinctive.