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.
What are links?
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 footnotes1 !
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.
What are the differences between links and buttons?
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:
- Links can be activated by pressing the return key only.
- Buttons can be activated by pressing return or space.
- Screen readers have a function to present a list of links to their users. Buttons cannot be as easily reached.
- Buttons use the normal mouse pointer arrow, while links trigger the use of the pointing hand mouse pointer.
As a developer, it is important to embrace that difference and know about it, as you can much easier meet user expectations that way.
What about styling links and buttons?
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.
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.
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.
- Footnotes are these small additional information section at the bottom of the page. Pretty much like this one. Actually, exactly like this one. ↩