Damien Robson

I've been asked the same set of questions quite a lot at work recently:

• "should this be a button or a link?"
• "can I style a link as a button?"
• "can I style a button as a link?"

After repeating the same information time and time again, I decided to do something more pragmatic about it. On the second Tuesday of every month, we host an Accessibility Guild, where any colleague who wants to can give a short presentation on an accessibility-focused topic, and this felt like the perfect opportunity to put together a presentation to put this line of questioning to bed once and for all.

Side note: don't get me wrong, I'm perfectly happy to help people out and don't mind being asked the same questions by different people. My reason for doing this stems from the fact that the same question kept coming up and clearly something wasn't sticking.

What follows is an abridged version of the presentation. Hopefully, dear reader, you can use it to glean answers and ideas that you can carry forward into your own projects, both personal and professional.

With that, let's dive in.

Links

What are they for?

Links are for navigation. They take your users to other pages within your site, other locations within the same page, or to a different domain altogether.

Which element?

Links are built using the a element.

Accessibility Features

• Links are announced as "link" to screen reader users, and they expect to be taken somewhere.
• Links are triggered with the Enter key.
• Links can be right-clicked for additional context such as opening in a new tab.

Styling

• If at all possible, keep the underline; if you can't, or your designs don't allow it, consider at the very least showing it on focus/hover.
• Ensure the "pointer" cursor is used.
• Make sure to use a high-contrast focus ring (see my Resources list for a great example).

Buttons

What are they for?

Buttons are for actions. They change things, submit things or trigger functional changes. Saving a form or opening a menu is a perfect use-case for buttons.

Which element?

Buttons are built using the button element.

Accessibility Features

• Buttons are announced as "button" to screen reader users, and they expect something to happen when interacted with.
• Buttons are triggered with both the Enter key and the Space key.
• Buttons cannot be right-clicked for additional context.

Styling

• More of a common practice than an crucial "rule", consider using the "pointer" cursor.
• Make sure to use a high-contrast focus ring (see my Resources list for a great example).

Common Issues

Links that are styled as buttons

Problem

Using a link because it looks like a button, but it performs an action

Solution

If the trigger performs an action (like "Submit"), use a button. If it must look like a button but actually navigates to a new page, use an a tag and style it, but ensure the accessible name and context remain clear.

Empty links

Problem

Using links to trigger menus

Solution

Use a button; links should not be used without a "real" destination. For example, a href="javascript:void(0)" is a non-functional link.

Custom buttons built with div or span elements

Problem

Building buttons with div or span elements because they offer easier styling

Solution

Use a button; divs and spans are structural elements that offer no native keyboard or mouse support when it comes to accessibility.

Silent buttons

Problem

Buttons that change the state of something (such as expanding/collapsing an accordion) without announcing it

Solution

Use ARIA attributes such as aria-expanded or aria-pressed to communicate button state.

Deciding which to use

Ask yourself the following:

Does it change the URL?

Use a link

Does it move focus to a different page?

Use a link

Does it toggle state (such as "like" and "dislike")?

Use a button

Does it open a modal or a drawer?

Use a button

An edge-case worth mentioning

It might be tempting to use role="button" with a link. Whilst this is fine in itself, ask yourself: can a button work just as well here? This is not always appropriate but is worth considering.

It's also worth remembering that your link's text can be used to determine mark-up, to an extent. For example, a link to "Get Started" may be styled as a button but the combination of the a tag and instructional text informs screen reader users that they're on a link, so the additional role isn't strictly required.

Key points

• Don't let "look and feel" dictate code.
• Try semantic HTML elements first (i.e. use a button before trying anything else).
• The moment you add a click handler to a link, it becomes a button.
• If it looks like a button, it should behave like a button for all users.

Hopefully that helps clarify things a little, but if not, you can always reach out to me on LinkedIn (opens in a new tab).