Button vs Link: Why the Difference Actually Matters

Modern interfaces blur the lines between design and interaction. Everything is tappable, clickable, swipable — and often styled to look the same. But in HTML, the difference between a <button> and a <a> is not visual. It’s semantic.

And if you care about accessibility, code clarity, browser behavior, or simply being understood — it matters a lot.

What’s at Stake Here?

Let’s be honest. You’ve probably seen (or written) code like this:

<a href="#" onclick="submitForm()">Submit</a>
<button onclick="window.location.href='/about'">Learn More</button>

It “works.” But it sends the wrong message — to assistive technology, to developers, and sometimes even to the browser itself. These little mismatches create UX bugs that are hard to track down — and even harder to justify in a code review.

So here’s the golden rule:
<a> is for navigation. <button> is for actions.

It’s that simple. And that powerful.

Use `<a>` for Navigation

If clicking something takes the user somewhere — a new page, a section, or even a route in a single-page app — it should be a link. The anchor tag was built for this.

Required: An href attribute — even if it’s href="#" (though that’s often a sign of misuse).
Good for: Site menus, text links, footers, logos, and social icons.

Browsers treat links differently. They support right-clicking to “Open in New Tab,” long-pressing on mobile, and tracking history state. These are navigation behaviors — and links unlock them.

Use `<button>` for Actions

If clicking triggers a function — like submitting a form, opening a modal, toggling a setting — you need a <button>. Not a styled link. Not a <div> with a click handler. A real, semantic button.

Supports: type attributes (submit, button, reset), disabled, and ARIA roles
Good for: Forms, toggles, drawers, modals, sliders, filters, mobile nav menus

Screen readers expect buttons to perform immediate, local tasks. Keyboard users expect to tab to them and activate them with Enter or Space. When you use the wrong element, you break these expectations.

“But I Styled It to Look Like a Button…”

Yes — CSS can make a link look like a button or vice versa. But style ≠ function.

A <div> with a click handler might look great — but it won’t be accessible by keyboard. It won’t announce itself as clickable to assistive tech. And it won’t behave correctly in a browser context menu.

That’s not progressive enhancement. That’s progressive confusion.

Behavioral Breakdown: What the Browser Actually Does

	`<a>`	`<button>`
Default keyboard behavior	Yes (Tab + Enter)	Yes (Tab + Enter/Space)
Right-click menu	Yes (Open in New Tab, Copy Link)	No
ARIA role	Link	Button
Acts as form submitter	No	Yes
Can be disabled	No	Yes

This is more than pedantry. It’s about **respecting the native behavior** of the platform — so the browser can help you instead of fight you.

Common Anti-Patterns (And What to Do Instead)

Using <a href="#" for modals or form submits
✘ Don’t. Use a real <button> and attach your JS logic cleanly.
Using <button> to link to another page
✘ Avoid. That breaks expectations — and sometimes, browser behavior.
Creating clickable cards with <div onclick>
⚠️ Wrap the whole thing in a link if it's navigational. Or use nested <button> actions if it's interactive content inside.

So What Does This Signal to a Professor?

This is about semantics, not style. About interface grammar. About teaching the browser and screen readers how to speak your UI’s language properly. If you write it clearly, everyone — from the end-user to the next developer — will understand what each element is for.

This is web literacy in action. And the code speaks volumes about your intent, experience, and empathy.

Final Thought

You don’t just write HTML to make things appear. You write it to make things understandable, operable, and trustworthy — across devices, abilities, and expectations.

Write it like someone will read it out loud. Because one day, a screen reader probably will.

Want help cleaning up the semantics in your UI? Or refactoring those click handlers into something more robust? Contact me here — and I’ll review it like it’s mine.