• Thu. Dec 9th, 2021

Buttons vs. Links · Eric Eggert

Byadmin

Oct 17, 2021


Should some links look like buttons, or should some buttons look like links? Twitter was all up in arms about this issue this week. Let’s take a look to see what these two UI elements are and what they do, and then, how they can look.

Links are interactive elements that usually link to another document, for example: Click this link to go to Knowbility’s website. There is some additional functionality, like the ability to point to different frames in a “frame set” (yup, you can still do that!) or forcing a download of a file.

In essence, the link changes what the URL in the browser points to and then displays that website or file. If the browser can’t display the file, it gets downloaded.

Links give you also several additional options in the right click menu: Opening the target page in a new window or tab, download the linked page, copy the link. When you hover over the link with the mouse, you can also see the destination of the link in the status bar.

In addition, some links only bring you to a different section of the same page, which is useful, for example navigating footnotes
!

What are buttons?

Buttons perform an action. When they were introduced as a variant of the <input> element, their sole purpose was to submit forms. They are still pretty great for that. Later, HTML introduced the <button> element, which allowed more versatility of buttons outside of forms.

While you can get redirected after a form submission, back in the day, the website would often just stay on the same URL and display a success message. With the <button> element, buttons can now be used for functionality all over the site that does not lead a user somewhere else.

Have a calculator on the site? A great use for buttons. Expand a navigation? Use a button. Show/hide something? A button can do that. Basically, a button would always be used either in a form or with JavaScript. Without JavaScript, the usefulness of buttons is severely limited.

First, they have two different roles, so assistive technologies announce them differently. Links are (shockingly accurately) announced as “links”, while buttons are announced as (you might have guessed it by now) “buttons”.

Having these different roles means there are different user expectations. Not only that links go somewhere and buttons do something, but also their interactivity:

As a developer, it is important to embrace that difference and know about it, as you can much easier meet user expectations that way.

The same principles apply to links and buttons for styling. Users generally will have the expectation that…

  • Underlined text goes somewhere.
  • Text in a pill or rounded rectangle shape does something.

That said, on the web there has not been much of a separation of the two than on desktop operating systems. The power of CSS to make every element look any way you like blurred the lines here.

Call-to-action links (CTAs) often have a button-like shape. At the same time, we might have lists of links that look nothing like those in the body of our texts for navigation or in a tag cloud.

This is usually not a problem because context is a thing that can help users to identify what’s going on. In a teaser that has a pill-shaped link that reads “Read the full story”, people will not confuse it with a button to do something on the page.

Imagine a button that is styled to look like a text link, but has a pencil icon and reads “edit”. There’s a good chance users won’t be surprised when they trigger an inline editing mode, which does not lead them to another page to do the edits.

Conclusion

Buttons and links are functionally different, but their styling can be similar. Use the proper tool for the job and remember that links go somewhere while buttons do something.

If you style them similarly, make sure that the functionality is clear from the context. You can add other clues to differentiate:

  • Make call-to-action links a more pill like appearance, if your action buttons are rounded rectangles; or the other way around.
  • Use iconography that supports the use. An arrow to the right on a call-to-action link is a great indicator to say, “this goes somewhere!” (To the left on right-to-left languages.)
  • Use meaningful descriptions as link or button text. “Download document”, “Submit form”, “Save progress”, “Read article” are all probably as or even more instructive to direct user’s expectations compared to the actual shape of the link or button.

You should care about the difference

With both elements in a gray area, it might not make a huge difference on what to use. And that might be true for the occasional link that should be a button, or for the individual button that just redirects you somewhere. But if you depend on the role of the element every day, like screen reader or speech input users do, the reliability of these very common elements is key.

If you had a keyboard and your “e” key would only work 90% of the time, it would be infuriating. Reliability and trust in user interfaces is important to allow users to navigate content and application with ease. If you use the right elements, you support users.

Did you like this article? Support my independent work with just €5/month.

That said, because of the complicated and diverse history of the web, in some instances there is no one true way to code or design something. Designs, development environments, approaches, and preferences can differ. Where I would have used a button and styled it that way, another user might have used a link. And that is totally OK.

Thanks to Hidde, Erik, and Nic, who reminded me about some things I forgot to mention in the first draft. Also, to everyone who shared their opinion and experience on Twitter. This is how we learn. And last, but not least, let me refer to Marcy Sutton’s talk “The Links vs. Buttons Showdown”, in which she comes to similar conclusions as I do. Carolyn reminded me of it via Twitter.





source

Leave a Reply

Your email address will not be published. Required fields are marked *