For several years it has been quite common for links and buttons to be styled in a similar matter - if not entirely the same. Only with the exception of regular links in body text, which thankfully is still consistent with the original purpose of the link element. My guess is that this originates from the ever-rising client-rendered web apps built on frameworks such as Angular, Vue and React where you can technically use links as if they were buttons. However, it’s still semantically incorrect and brings other issues.
Staying true to the element’s original purpose
Except for simply being semantically incorrect, it’s also important to distinguish them from one another because they;
a) behave differently and
b) as a user I have different options in which way I can interact with them. A link can be copied, opened in a new tab or bookmarked for later access. A button can submit a form, reset a form or be in a disabled state.
To be consistent, they should remain true to these purposes.
If you have ever been through the online shopping experience you have most likely noticed that when browsing products, the products themselves are links to different pages. This is of course useful since the user can further browse the product in detail, bookmark and even open multiple product pages by using multiple tabs.
In that case it might be obvious to use a link. But what if we consider the actual checkout process once the user has added the desired products to the shopping cart? Completing the checkout process and confirming the order is of great importance for the user as well as the seller. This is why we want to properly guide the user. The checkout interaction might take me somewhere else, to an order summary or receipt. Should we style it as a link then? That makes it visually weak. Do we style it as a button? That defies the element’s original purpose. Herein lies the problem.
The definitions are simple
Let’s have a look at the definitions of a button and a link respectively. Mozilla describes an <a> tag as:
The HTML <a> element (or anchor element), along with its href attribute, creates a hyperlink to other web pages, files, locations within the same page, email addresses, or any other URL.
Buttons can be an element of its own but can also be used as input elements with a type defined, either ‘submit’ or ‘button’, but for the sake of brevity I will refer to all of them in this post as buttons.
The <button> tag is defined by Mozilla as:
The HTML <button> element represents a clickable button, which can be used in forms or anywhere in a document that needs simple, standard button functionality.
Interpreting these definitions, you could say that buttons are used to interact in the current context and affect the website, be it visually or adding, editing or removing content. Links, however, don't affect the website and instead let the user contextually move on.
Simply put; links take [the user] somewhere. Buttons do something [for the user].
The definitions are not quite as simple to follow
As with most things, there’s no rule without an exception, which leads to my next point. Getting back to the case above; clicking the 'checkout' might lead the user to a summary of the order or a receipt and it also does something for the user. It's still not clear whether we use a button or a link. As stated earlier; if it leads me somewhere else, it's technically most likely a link. So we might use a link, but as also mentioned earlier; that makes it visually weak.
What if we instead consider the user intent? In the final step of an order process; do I expect to navigate or to perform an action? I need to feel confident my intended action has been executed. Which type of element offers the most sense of finality to the interaction? Buttons, since they are supposed to do something for me.
User expectation, not technical implementation
Evidently, there is no easy way to have the elements remain true to their original purpose while allowing for ‘call-to-action’ links to stay visually strong. Therefore, my take is to not design [for what the element technically does] but [for what kind of interaction the user expects].
Technically, clicking on ‘checkout’ might lead me to another page, but the expectation will nevertheless be that I am confirming the order placement – in other words; the click does something [for the user].