Skip Navigation

Should I Use a Button or a Link?

Published


One of the most seemingly contentious questions in web accessibility is whether or a button or link should be used when creating certain kinds of interactive elements. Why is it so contentious? The question has been answered countless times over the years by accessibility experts. There is also a wealth of reference documentation that answers the question.

The answer is straightforward, and I think it’s only contentious when there is lack of consideration of why links and buttons both look different and behave in completely different ways.

Existing resources

Before reading the rest of this article, I highly recommend reading the wealth of knowledge that’s already out there. Here’s a list a small list to get you started:

First, it’s important to understand how buttons and links differ. I’ve seen them mistakenly conflated and oversimplified as elements that “perform an action”. And while they both enable a user to perform different actions, that doesn’t make them the same element.

We’ll answer the question of differing behavior by reading some bits of the HTML Living Standard and WAI-ARIA 1.2.

Note: This article only discusses the HTML <button> and <a> elements.

The HTML Living Standard also talks about the <link>, <area>, and <form> elements in the context of links, but we won’t discuss those here since they have different purposes than the <a> element.

The HTML Living Standard has an entire section dedicated to links. Here’s the paraphrased definition provided by that document:

Links are a conceptual construct that represent a connection between two resources.

It goes on to say there are two types of links: links to external resources and hyperlinks. Let’s look at some examples of each.

Links to external resources are resources outside of the current site. These can be denoted by setting the rel property to "external", and then they can also have unique styling applied to them using a CSS attribute selector like a[rel="external"]. As an example, you might choose to append the text “(external link)” to every link with rel="external". This can be done with CSS like this:

a[rel="external"]::after {
  content: " (external link)";
}

Related concept: Warning users of context changes in advance to minimize confusion

You can also apply special styles to to links with target="_blank". In the following example, the text “(opens in new tab)” is appended to the link to give users a warning that multiple context changes will happen when the link is activated.

a[target="_blank"]::after {
  content: " (opens in new tab)";
}

This is related to Success Criterion 3.2.5: Change on Request, which says:

Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

It’s important to warn users that context will change with an action for many reasons. Some users may not be able to detect changes in context because of cognitive limitations or visual, reading, or intellectual disabilities. For users with limited motor control, unexpected and unwanted context changes will cause extra effort on their part to get back to where they were.

It’s best to give users all the information they need to make an informed and empowered decision for themselves.

Hyperlinks are links to resources within the current site. Here are some examples:

According to the HTML Living Standard, there are several values for the rel property on <a> elements that designate the element as a hyperlink: alternate, author, bookmark, help, license, next, prev, search, and tag.

I don’t include this long list of values because I think it’s important to know each one. I include it so it’s more obvious just how much functionality is handled by native <a> elements. You may have heard that you can apply role="link" to <button> elements when you want to turn them into links, but it’s just not enough.

There is a major loss in functionality by not using a native <a> element when you want to render a link, and this one property we’ve discussed only brushes the surface. The first rule of ARIA is extremely important to note here:

If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

We have one more topic to cover for defining links, and that’s the link ARIA role. link is the default role for <a> elements. Here’s how the role is defined:

An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource.

There is also a note that reads:

If pressing the link triggers an action but does not change browser focus or page location, authors are advised to consider using the button role instead of the link role.

With all of the information we have covered so far, I think we can move forward with the following definition for links: An element that connects two resources and does one of the following when activated: downloads the linked resource, changes the browser focus to another part of the page, or changes the browser’s location to another page.

About Buttons

Let’s move on to defining buttons. We’ve already seen a little bit of information that tells us buttons are different from links, but let’s look for some more so we’re well equipped for inevitable future buttons vs. links debates. The HTML Living Standard does not give us as much non-technical information about buttons as it does about links, so I’ll rely on the MDN Web Docs and WAI-ARIA 1.2 Specification for definitions.

The <button> element

The MDN Web Docs definition for the Button element reads:

The <button> HTML element is an interactive element activated by a user with a mouse, keyboard, finger, voice command, or other assistive technology. Once activated, it then performs a programmable action, such as submitting a form or opening a dialog.

Shameless plug: I wrote this definition back in March of 2022. 🥳

Take a look at the long list of attributes the button element accepts:

That is a lot of functionality. This list should serve as another reason why it’s not a good idea to mix and match the <a> and <button> elements. Just applying role="button" to <a> elements is no where near enough to make the anchor elment match the native implementation of the button element. In fact, just changing a role does not change the look or behavior of an element at all if you’re not using assistive technology.

The button ARIA role

The WAI-ARIA 1.2 Specification says the button role is:

An input that allows for user-triggered actions when clicked or pressed. […] Buttons are mostly used for discrete actions. Standardizing the appearance of buttons enhances the user’s recognition of the widgets as buttons […].

This says that buttons are typically used to perform a single action at a time. It also says that users benefit from their appearance being standardized, so they are recognizable as an interactive element.

There’s one supported ARIA state for the button role that the link role does not have. That state is aria-pressed. It communicates the “pressed” state of toggle buttons. This is not a quality of a <a> elements. It’s another example of just how much buttons and links differ from one another.

Related concept: `aria-checked` and `aria-selected`

The aria-pressed state is similar to the aria-checked and aria-selected states.

The Button WAI-ARIA Widget

The ARIA Authoring Practices Guide (APG) is a useful for resource for learning about accessibility semantics and keyboard interfaces. It has several examples of commonly used widgets. It also includes resources on common practices.

One of its widget examples is the Button widget. Right after defining the widget and naming two additional supported button types (toggle and menu), it calls out the importance of distinguishing links and buttons:

The types of actions performed by buttons are distinctly different from the function of a link. It is important that both the appearance and role of a widget match the function it provides.

It also notes that sometimes links have the visual style of a button, but it says there’s still a better solution: adjust the design.

Nevertheless, elements occasionally have the visual style of a link but perform the action of a button. In such cases, giving the element role button helps assistive technology users understand the function of the element. However, a better solution is to adjust the visual design so it matches the function and ARIA role.

By now, we should have a pretty good idea how different links and buttons are. I’ll still list a few more examples of differences:

How many more user agent or assistive technology features are broken by poorly coded elements? I don’t know. Do you want to test every single one and find out? I highly doubt it. Just use native HTML elements!

Remember the first rule of ARIA use:

If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

And don’t forget the second rule of ARIA use:

Do not change native semantics, unless you really have to.

The native semantics are present for a reason. I promise no one put them there to make your software development life more difficult. They’re there to make websites usable by everyone. You want more users, right? You want them to be happy and impressed with your hard work, right? :)

There are four principles of accessibility that inform how we must build the web and content for it. You can remember them with the acronym POUR: information and interfaces must be Perceivable, Operable, Understandable, and Robust. The Web Content Accessibility Guidelines (WCAG) are organized under these 4 principles. I’m not taking a deep dive into all of them here, but if you want to start on your own the latest standard is WCAG 2.1.

Anyways, what does the look of buttons and links have to do with four principles of accessibility? Well…

Here are some WCAG guidelines and success criteria relevant to this topic you may find insightful:

So what’s the answer?

I think most people already know the answer to this question, and many of those who scour the internet for a different answer are looking for “permission” to do something they “unconventional”. But to end on a very clear note:

Back to Top