Links vs. Buttons vs. Submit Inputs: The Accessibility Breakdown

One of the most common questions I hear in website evaluations is: “Is there a clear benefit to using a link over a button, or is it just personal preference from a front-end developer’s perspective?”

And let me tell you—this isn’t just a stylistic choice. There’s a real accessibility and usability reason why you should choose one over the other, depending on what you’re trying to do.

Let’s break it down.

---

Links (<a>) vs. Buttons (<button>): What’s the Difference?

The easiest way to remember this:

• If it navigates somewhere, use a link (<a>).
• If it performs an action on the same page, use a button (<button>).

Simple, right? But let’s dig into the why.

When to Use a Link (<a>)

Use a link when clicking on it takes the user to another page, section, or external resource. This could be another page on your site, a document, or an external URL.

Key Benefits of Links:

• Expected behavior: Users expect links to navigate. They can right-click, open them in new tabs, bookmark them, or share them.
• Keyboard & screen reader support: Links are natively focusable, announced as “link,” and easy to interact with.
• SEO & browser defaults: Links are crawlable by search engines and behave predictably across all browsers and devices.

Common Misuse:

❌ Using a <button> and trying to make it behave like a link by adding window.location.href = 'somepage.html'. That’s bad for accessibility and adds unnecessary JavaScript. And unnecessary JavaScript requires adding appropriate ARIA to make sure everyone can access the information. Remember: the best ARIA is not having to use ARIA.

✅ Instead, just use <a href="somepage.html">Go to page</a>.

---

When to Use a Button (<button>)

Use a button when clicking on it triggers an action on the same page—like submitting a form, opening a modal, toggling content, or triggering JavaScript functionality.

Key Benefits of Buttons:

• Expected behavior: Users expect buttons to perform actions, not navigate away.
• Keyboard & screen reader support: Buttons are natively focusable and work with Enter and Space keys.
• No default navigation behavior: Prevents accidental navigation issues that can happen if a link is misused.

Common Misuse:

❌ Using <a href="#"> to trigger a JavaScript action. If there’s no destination, don’t use a link.

✅ Instead, use <button> and attach JavaScript to handle the interaction.

---

What About <input type="submit">?

Now, what about form submission? Here’s where the choice is between <button type="submit"> and <input type="submit">.

Using <input type="submit">

This is the old-school way of adding a submit button.

✔️ Pros:

• Works right out of the box for form submission.
• Recognized by screen readers as a submit button.
• Simple and doesn’t require JavaScript.

❌ Cons:

• Limited styling: Harder to customize compared to <button>.
• Can’t contain other elements: You can’t add icons or extra formatting.
• Less flexible: If you need to run JavaScript alongside submission, <button> is a better choice.

Using <button type="submit">

This is the better option if you want more control.

✔️ Pros:

• Can be fully customized with CSS.
• Can include icons or additional text inside.
• Works seamlessly with form submission.
• More flexible—can be used for different button types (submit, reset, button).

❌ Cons:

• You have to explicitly set type="submit" to avoid unexpected behavior.

---

The Accessibility Takeaway

If you want a quick TL;DR:

• Use <a> for navigation.
• Use <button> for actions.
• Use <button type="submit"> for form submission unless you need something super simple—then <input type="submit"> works fine.

And whatever you do—don’t use a link (<a>) styled like a button for interactive elements. That’s an accessibility fail, and we don’t do those around here.

Got any other web accessibility questions? Drop ‘em in the comments!