Buttons vs Links

In web design, it’s not uncommon to see links styled as buttons if we want those links to stand out and look more like a call-to-action. In WordPress, it’s also not uncommon to use links to trigger actions on a page such as opening a modal or a dropdown.

Given this, it’s not surprising that many people don’t realize the difference between and HTML button and link, but when it comes to accessibility, it’s important to know the difference between buttons and links and how to use their respective HTML tags correctly.

The Difference Between Buttons and Links

In HTML, a button is coded with a <button> tag. Buttons are typically used to trigger an action on the current page, such as submitting a form or opening or closing a modal. HTML buttons can be triggered by keyboard with either the return/enter key or the spacebar.

Links are coded with an <a> tag and are used to navigate between pages, to a different section of the current page, or to external resources like documents or other websites. Links can only be triggered on the keboard with the return/enter key.

How Screen Reader Users Experience Buttons and Links

When a screen reader user encounters a button or link, their screen reader is going to read the HTML tag and tell them if they are on a button or a link, and then read the text or aria-label for that button or link.

So for a link like this: <a href=”/about”>Learn More About Us</a>, a screen reader user would hear, “Link. Learn more about us.” This is same even if that link were styled to look like a button (for example by adding class=”button” to the link), because the screen reader is using the <a> tag to know that this is a link.

If the element was a button, like this: <button>Close Popup</button>, they would hear, “Button. Close popup.”

Common Button and Link Mistakes on WordPress Websites

As mentioned above, it’s not uncommon to see buttons and links get confused on WordPress websites. Here are two examples that we see frequently when doing accessibility audits for WordPress websites.

Links That Should Actually Be Buttons

If you have something on your website that triggers an action on the page, that element should be coded as a button not a link. Here are examples of elements that should be buttons, not links:

• Open and close buttons for mobile navigation.
• Top-level menu items that are not linked to a page but only open a dropdown menu.
• Anything that triggers a modal or popup to open.
• Buttons or text that, when clicked, opens an accordion.
• Dot navigation and previous/next buttons on carousels.

If you’re not sure if you have links that should actually be buttons, a quick way to tell is by checking to see if you have any links that are either missing an href attribute completely or if they are linking to a hashtag only like this:

<a href=”#”>About</a>

In the Equalize Digital Accessibility Checker plugin, we flag links like this with an “Improper Use of Link” error because they’re likely not doing anything or they’re doing something with JavaScript, which is an indication that the element is functioning as a button instead of a link.

Links Incorrectly Given the Role of Button

Sometimes overzealous developers try to be helpful by adding attributes to their links that define them as buttons when they shouldn’t be. This is an example of a link that has been given a role of button:

<a href=”/about” role=”button”>Learn More About Us</a>

When a screen reader encounters this link, it would not read it as a link to the user, rather it would say, “Button. Learn more about us,” as if the link were a button.

In this case, the element is not a button, it is a link to another page, so this would be very confusing to users and is incorrect.

Beaver Builder and Elementor users take note: this is a problem with the “button” module in both of those popular page builders and needs to be fixed to improve the accessibility of websites built with these page builders.

Why does using buttons and links correctly matter?

Using the correct HTML tags for buttons and links is important because it can disorient users if they hear the wrong tag read out to them by the screen reader.

Because links are used for navigation and buttons are used for actions, when screen reader users hear “link” or “button,” they have a specific expectation for what that element will do if triggered. For example, if a link has a role=”button” on it and is read out to users as a button, they might click it expecting an action to be performed on the current page; when a new page opens instead, this can lead to confusion and frustration.

Additionally, links and buttons can be triggered differently on a keyboard, and hearing the HTML tag give users an expectation of how they should be able to interact with that element.

Fixing Incorrectly Coded Buttons and Links

Unless you coded the incorrect buttons or links that are being added, you’re likely going to either need to (a) reach out to the theme or plugin dev or (b) code JavaScript to fix the issue. Here are some resources for fixing the examples listed above.

• JavaScript to remove role=button from Elementor links
• Fixing button role on links in Beaver Builder
• How to add custom attribute to a nav menu item in WordPress (this would be how you could add role=”button” to menu items that are actually buttons).

Note, while you can add ARIA role=”button” to anything to tell a screen reader that the element is a button, it won’t add button functionality, so you’ll need to add additional ARIA attributes or write JavaScript to add button functionality. Read more about that in the ARIA: button role documentation on Mozilla developer docs.