Jake Worth

Jake Worth

Button, Link, or Neither?

Published: December 03, 2022 • Updated: December 13, 2022 4 min read

  • ux

Links, buttons, spans, and divs– what should we be presenting to a user to click? In this post, I’ll share some best practices for clickable elements.

To summarize:

  • Most clickable elements should be links or buttons
  • Use buttons and links for the right jobs
  • Clickable elements need signifiers

Most Clickable Elements Should Be Links or Buttons

Peruse a JavaScript frontend, and you’ll find many clickable elements that are not buttons or links: divs, spans, trs, etc. Sometimes there are no actual button tags at all!

Most clickable things should be links or buttons. You can bend more things than you think into one of these elements. Using links or buttons makes the document better because it will be more semantic and accessible.

Let’s look at each of those terms.


Semanticism is a noble goal in frontend programming: tags have meaning and the document can be understood.

When you use a link or button, you’re writing markup that has its own meaning and reinforces the semantic tradition. It will just be better understood overall by any consumer than meaningless tags.

A bit of support from the React docs on accessibility:

“Semantic HTML is the foundation of accessibility in a web application. Using the various HTML elements to reinforce the meaning of information in our websites will often give us accessibility for free.”


Links and buttons are always going to be more accessible clickable lements than their competitors. Assistive technologies are getting smart these days: give a div a click handler or even a class with the substring ‘btn’ in it, and some screen readers can determine that it’s clickable. But why take that chance?

Use Buttons and Links for the Right Jobs

Buttons and links do different things.

A decent mental model: buttons “do something” and links “go somewhere.” This is getting blurry these days! In a modern JavaScript application, many clicks that go somewhere also do a lot of things.

Here’s an alternate mental model: what would the customer think is happening? When they click “log out”, what would be their mental model? That’s what you should do.

A programmer knows that logging out is doing something: changing state. A customer might think something similar, that it’s doing something called logging me out. The fact that it goes to the login page afterwards may not be a big consideration. I’d implement it as a button.1

A few more examples:

  • Updating the user’s profile? Button
  • Visiting the dashboard? Link
  • Skipping a step in a wizard? Link
  • Closing a modal form? Button
  • Sending a chat message? Button

When it doubt, be consistent.

Clickable Elements Need Signifiers

Clickable elements need signifiers.

In The Design of Everyday Things, Don Norman discusses affordances and signifiers. An affordance defines what actions are possible, and signifiers are perceptible signals about what can be done. Links and buttons have clear signifiers; when you’re using something else, you need to add signifiers.

Link signifiers are universal. Links are a different color, are often underlined, and have a pointer cursor that makes that little hand show up when you hover on them. Many have a hover state and most have a visited state.

Button signifiers tend to benefit from skeuomorphism– they look physical buttons. Many have hover states, some have pointer cursors, some have processing states like spinners, changing text, or temporary disability when processing.

Clickable things that are not links or buttons need signifiers, too. Sometimes they are in a context like a settings menu where almost everything is clickable, and that’s enough. Other times, you might need to add a border, pointer cursor, call to action, or hover state. Pick one or multiple.

A clickable div without signifiers, that is ignored by assistive technology, is invisible. Add signifiers.

Putting It All Together

To summarize:

  • Most clickable elements should be links or buttons
  • Use buttons and links for the right jobs
  • Clickable elements need signifiers


A “log out” button with a hover state and a pointer cursor. When you click it, it’s disabled with a spinner, and when complete, the customer is logged out.

An “about us” link in the footer of a webpage. It’s rich with signifiers like an underline, hover and visited colors, and a pointer cursor. When a customer clicks it, they see the “About Us” page.

A “subscribe” button next to an email input for a newsletter subscription. Clicking it submits an email.

Here’s one non-link/button example:

A clickable row in a table. It has to be a tr because of table nesting rules, but we want it to be clickable, so this is a rare exception to our first argument. To compensate for not using a button or link, we’ve added signifiers of a border, a hover state, and a pointer cursor. And we aren’t confusing the UX with links or buttons inside the row that draw attention away from it and fight for click captures.

If you follow these principles, you’ll have interactivity that makes sense.

  1. This example UX problem is often implemented as something that looks like a link. Stay safe out there.

Get better at programming by learning with me. Subscribe to my newsletter for weekly ideas, creations, and curated resources from across the world of programming. Join me today!