A link is not a button, and a button is not a link

One of the fastest ways to spot an inexperienced front-end developer is to look at how they handle links and buttons.

It sounds trivial. It's not.

Many accessibility problems start with developers choosing the wrong HTML element and then trying to force it to behave like something else.

A link is for navigation.

A button is for actions.

Those two things are not interchangeable.

Unfortunately, modern websites are full of links that act like buttons, buttons that act like links, and clickable <div> elements pretending to be both.

The page may look fine. The accessibility experience is often a mess.

The rule is simple

If clicking an element takes the user somewhere else, use a link.

<a href="/products/wheelchair-ramp">
    View product details
</a>

Examples include:

• Opening a product page
• Reading a blog article
• Downloading a PDF
• Navigating to another page
• Jumping to another section of the same page
• Opening an external website

If clicking an element performs an action on the current page, use a button.

<button type="button">
    Open menu
</button>

Examples include:

• Opening a modal window
• Submitting a form
• Expanding an accordion
• Toggling a menu
• Applying a filter
• Adding an item to a shopping cart

That's the entire decision process.

Yet many websites get it wrong.

Why assistive technology users care

Most users never think about the difference between a link and a button because they interact visually.

Screen reader users don't.

Assistive technologies expose links and buttons differently because they serve different purposes.

When a screen reader announces "link," users expect navigation.

When it announces "button," users expect an action.

Those expectations are built from years of using websites.

When a developer creates a link that opens a modal window instead of navigating, the user receives one message and experiences something entirely different.

The result is confusion.

Accessibility failures are often caused by broken expectations rather than broken functionality.

Keyboard behavior is different

Links and buttons also respond differently from the keyboard.

A standard button can be activated with both Enter and Space.

A standard link is typically activated with Enter.

Many developers discover this only after replacing native controls with custom JavaScript components.

They create a clickable <div> element, attach an event listener, and assume the job is finished.

It isn't.

Now they must recreate:

• Keyboard support
• Focus management
• Screen reader semantics
• Disabled states
• Accessible names
• Expected browser behavior

Native HTML already provides all of that.

Throwing it away creates work and usually introduces accessibility bugs.

The problem with fake links

One of the most common accessibility mistakes is using an anchor tag without an href attribute.

For example:

<a onclick="openModal()">
    Open dialog
</a>

Visually, this may look like a link.

Semantically, it often isn't.

Many assistive technologies will not treat the element as a true link because it lacks a valid destination.

The developer sees a link.

The screen reader user may not.

This creates inconsistent experiences across browsers and assistive technologies.

A button would have been the correct solution from the beginning.

The problem with fake buttons

The opposite mistake is equally common.

A developer creates a button and uses JavaScript to redirect the user to another page.

<button onclick="window.location='/contact'">
    Contact us
</button>

The visual result works.

The semantic meaning is wrong.

Users are told they are activating a button. Instead, they are taken to another page.

That disconnect may seem minor to a developer testing with a mouse, but it creates unnecessary friction for users who depend on predictable behavior.

If the purpose is navigation, use a link.

Buttons can do things links cannot

Another reason the distinction matters is that buttons and links have different capabilities.

Buttons can be disabled.

<button disabled>
    Submit
</button>

Links cannot.

Buttons participate naturally in forms.

Links do not.

Buttons are designed for user actions.

Links are designed for destinations.

Trying to force one element to behave like the other usually leads to extra code and more accessibility issues.

How screen reader users navigate

Many developers are surprised to learn that screen reader users often navigate pages by pulling up lists of links or lists of buttons.

Instead of reading every word on a page, they can jump directly between interactive elements.

Imagine a user opening a list of links and hearing:

• Open menu
• Expand section
• Show filters
• Close dialog

Those are actions, not destinations.

They should have been buttons.

Now the page structure no longer reflects reality.

The user has to spend additional time figuring out what each control actually does.

A real-world example

A law firm website recently used anchor tags for every accordion section on its FAQ page.

Each question was coded as a link.

Clicking the link did not navigate anywhere. It simply expanded hidden content below the question.

The design worked visually.

The accessibility experience did not.

Screen readers announced every question as a link. Keyboard users expected navigation. The code provided neither.

Replacing the links with native buttons required only a few minutes of development time and immediately fixed the semantic issue.

No redesign was necessary.

No accessibility widget was required.

Just better HTML.

A practical checklist

Use a link when:

• The user navigates to another page
• The user opens an external website
• The user downloads a file
• The user jumps to another section of a page
• The user opens a document or resource

Use a button when:

• The user submits a form
• The user opens or closes a modal
• The user expands or collapses content
• The user toggles a menu
• The user changes a setting
• The user filters search results
• The user performs an action without leaving the page

Good accessibility starts with HTML

Many accessibility audits focus on ARIA attributes, color contrast, focus indicators, and automated testing tools.

Those issues matter.

But a surprising number of ADA compliance failures originate from something much simpler: choosing the wrong HTML element.

Developers often spend hours writing JavaScript to make custom controls behave correctly when the browser already provides accessible controls for free.

A link is not a button.

A button is not a link.

The browser knows the difference. Screen readers know the difference. Keyboard users know the difference.

Your HTML should know the difference too.