Buttons vs. Links

No, they are not the same.

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 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.

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.

Support Eric’s independent work

I'm a web accessibility professional who cares deeply about inclusion and an open web for everyone. I work with Axess Lab as an accessibility specialist. Previously, I worked with Knowbility, the World Wide Web Consortium, and Aktion Mensch. In this blog I publish my own thoughts and research about the web industry.

Sign up for a €5/Month Membership Subscribe to the Infrequent Newsletter Follow me on Mastodon

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.

  1. Footnotes are these small additional information section at the bottom of the page. Pretty much like this one. Actually, exactly like this one.

Comments & Webmentions

♻️

  • 💬
    2022-01-11 12:55
  • 💬
    2022-01-11 14:35

    You have consumer power etsy.com/uk/listing/109…

  • 💬
    2022-01-11 13:40

    congrats, you triggered the tshirt generator bots

  • 💬
    2022-01-11 13:35

    Order here
    ttasnim.com/6450?name=appa…

  • 💬
    2022-01-11 16:15

    Damn, I thought you were talking about @stevefaulkner. :(

  • 💬
    2022-06-10 11:40

    The overlap in use cases doesn't bother me so much, but I think I feel more strongly than you do about the styling. The differences in keyboard interaction, browser functionality, and screen reader listing are enough for me to want to be more strict about differentiating styling.

  • 💬
    2022-07-28 21:45

    Cheers, Kev. Remind me, where do I send the tenner?

    Anyhoo, this one?

    tpgi.com/enough-with-th…

    But it's not really about the design considerations of whether a link should look like a button (or vice versa). More: "Stop making it so bloody difficult for yourselves"

  • 💬
    2022-07-28 21:45

    That’s the one!

  • 💬
    2022-07-29 01:05

    Right!! Thanks I read this last year too but completely forgot thanks 🙏🏻

  • 💬
    2022-07-28 21:30

    I’m sure @lloydi did a brilliantly written piece on this (with his usual sarcasm in there to boot)

  • 💬
    2022-07-29 01:10

    Yeah firmly on board for this stance ha

Preferences (beta)

Select a Theme
Font Settings

Preferences are saved on your computer and never transmitted to the server.