Semantic Links vs Buttons

Use links for navigation to another location or resource, and buttons for actions that change state or trigger behavior. Choosing the correct element preserves expected browser behavior, keyboard interaction, and accessibility semantics.

An HTML `<a>` element represents a hyperlink: activating it takes the user to a URL or another document location. A `<button>` represents an interactive control that performs an action, such as submitting a form, opening a dialog, toggling content, or triggering application logic.

Links have built-in browser behavior such as opening a destination in a new tab, copying a link address, and navigating with standard keyboard controls. Buttons instead participate in control interaction and do not inherently represent a destination URL.

The distinction should be based on intent, not appearance. A control styled like a button can still be a link if its purpose is navigation, while a visually text-like control should still be a button if it performs an action without navigation.

Avoid replacing these elements with generic `<div>` or `<span>` elements plus click handlers. Doing so requires recreating keyboard support, focus behavior, and accessibility semantics that native elements already provide.

Key points

• Use `<a href>` when activation navigates to a URL or document location.
• Use `<button>` when activation performs an action or changes application state.
• Do not choose the element based only on visual styling.
• Prefer native semantics over clickable `<div>` or `<span>` elements.
• Preserve expected keyboard, browser, and assistive-technology behavior.

Interview questions

When should you use a link instead of a button?

Use a link when the user's primary intent is to navigate to another URL or location. Use a button when the interaction performs an action on the current page, such as opening a dialog or submitting data. The choice should follow the control's meaning rather than its visual appearance.

Why is `<a href>` preferable to a clickable `<div>` for navigation?

An anchor with `href` communicates that the element is a link to browsers and assistive technologies. It also provides native keyboard interaction and browser features such as opening the destination in a new tab. A clickable `<div>` requires developers to recreate much of this behavior manually.

Is it okay to style a link so it looks like a button?

Yes. Visual styling does not determine semantic meaning. A navigation control can use an anchor and receive button-like CSS while remaining a link. This preserves navigation semantics while allowing the design system to use a consistent visual treatment.

What is wrong with using a `<div>` with an `onclick` handler for an action?

A plain `<div>` does not have the native button semantics expected by assistive technologies. It also does not automatically provide the same keyboard interaction and focus behavior as a button. Developers can add these behaviors, but using `<button>` is simpler, clearer, and less error-prone.

How would you decide between a link and button in a component API?

I would model the component around its semantic purpose rather than expose a single element whose meaning changes implicitly. A navigation variant should render an anchor with a meaningful `href`, while an action variant should render a button with appropriate button behavior. This keeps browser behavior, accessibility semantics, and testing expectations aligned with the component's intent.