Some of the web’s design and development practices have led to buttons and links becoming conceptually bundled together and misunderstood. Practitioners can fall into the trap of seeing the surface-level commonality that “you click the thing, then something happens” and mistakenly thinking the two elements are interchangeable. Some might even consider them as a single “button component” without considering the distinctions underneath. However this mentality is harmful for effective web development and causes our users problems. In this post I’ll address why buttons and links are different and exist separately, and when to use each.
Problematic patterns #
Modern website designs commonly apply the appearance of a button to a link. For isolated calls to action this can make sense however as a design pattern it is often overused and under-cooked, which can cause confusion to developers implementing the designs.
Relatedly, it’s now common for Design Systems to have a Button component which includes button-styled links that are referred to simply as buttons. Unless documented carefully this can lead to internal language and comprehension issues.
Meanwhile developers have historically used faux links (
<a href="#">) or worse, a DIY clickable
These patterns in combination have given rise to a collective muddle over buttons and links. We need to get back to basics and talk about foundational HTML.
Buttons and anchors in HTML #
There are two HTML elements of interest here.
What we refer to as a link is implemented using the HTML anchor element (
Meanwhile buttons (by which I mean real buttons rather than links styled to appear as buttons) are implemented with the HTML button element (
- goes somewhere (i.e. navigates to another place)
- normally links to another document (i.e. page) on the current website or on another website
- can alternatively link to a different section of the same page
- historically and by default appears underlined
- offers specific right-click options to mouse users (open in new tab, copy URL, etc)
- uses the “pointing hand” mouse pointer
- can be activated by pressing the return key
- is announced by screen readers as “Link”
- is available to screen reader users within an overall Links list
- does something (i.e. performs an action e.g. "Save" or "Show")
- can be used to submit forms as a replacement for
<input type=submit />and is a better approach since it is easier to style, allows nested HTML and supports CSS pseudo-elements
- historically and by default appears in a pill or rounded rectangle
- uses the normal mouse pointer arrow
- can be activated by pressing return or space.
- is announced by screen readers as “Button” (no need to explicitly apply the ARIA button role)
- unlike a link is not available to screen reader users within a dedicated list
Our responsibilities #
It’s our job as designers and developers to use the appropriate purpose-built element for each situation, to present it in a way that respects conventions so that users know what it is, and to then meet their expectations of it.
- Visually distinguish button-styled call-to-action links from regular buttons, perhaps with a more pill-like appearance and a right-pointing arrow
- Avoid a proliferation of call-to-action links by linking content itself (for example a news teaser’s headline). Not only does this reduce “link or button?” confusion but it also saves space, and provides more accessible link text.
- Consider having separate Design System components for Button and ButtonLink to reinforce important differences. Note to self: we don’t do this at work but maybe we should!
button. However in disclosure patterns where the trigger and target element are far apart in the DOM it can make sense to use a link as the trigger.